inmarket

uGFX works on the raspberry pi. It however uses the CPU not the GPU for rendering due to datasheets for the GPU being unavailable. You can however use the Xlib uGFX driver to indirectly use the GPU via the closed source X driver. In practice it is likely the CPU rendering will be faster anyway except for things like video decoding. Personilisation of all GWIN graphic elements is possible as part of the uGFX design. Custom controls can also be easily built. All the uGFX source code is also publically available. Yes, uGFX supports touch but only single point touch. As such it understands simple single point guestures. Anything else needs to be decoded by your application. In practice very few controllers are capable of supporting more than single touch anyway particularly in the embedded environment.

V3 currently has no planned release date although I am hoping around June/July. V2.8 and V3.0 will be released simultaneously with V2.8 being the last V2 release. The major differences so far with V3 are: 1. A new gdisp driver interface. This will have improved efficiency, improved features, can all be added to a project via config variables, and is compatible with single file make. Adding a gdisp driver at link time is no longer required. 2. Renaming of certain types and color constants to remove name conflicts. V3.0 has a GFX_COMPAT_V2 config that is set on by default that will enable existing uGFX applications to compile and run (but not drivers). As part of the gdisp driver rewrite for V3.0, it is planned that the 2nd layer of the STM32 LTDC will be exposed and this should allow all sorts of groovey effects (including double buffering). One if the main purposes of V3 is to move to a point where the entire uGFX (including drivers) can be built using single file make. That may happen in V3.0 but more likely it will be V3.x. Unfortunately the largest amount of queries we get is "how do i add uGFX to xyz IDE". Single file make solves those issues and also significantly speeds up the compile. It also aids technology that we are working on for the new version of Studio. If you have a list of things that you would like to see please send them. We can't guarantee anything but if it fits the development plan we will add it.

The initialisation code was based on code originally provided by STM for the stm32f4-discovery board. There was however an issue that caused extreme flickering of the display. From memory the clock rate was increased and this solved that problem. This change might be what you are seeing and it might have been incorrectly rippled into the f7 code although the f7 code is also based on code provided by STM. Unfortunately it has been too long ago. As this code works on the f7 when running raw32 it has always been my suspicion that ChibiOS has changed the clock settings or the gpio arrangements thus preventing the lcd from working. I have followed the gpio aspect of that to no avail leaving clocks as the likely culprit. Note that even in the original STM code the code comments were not always correct.

Always glad to help.

I would suggest the following approach... 1. Simplify the program until you have only the buttons of concern and their associated images. As you strip code out that will quite often show where the problem originates. 2. Once you have a short test program that still exhibits the problem play with stack size in case it is a stack overflow issue. 3. Try putting long gfxSleepMillseconds (in the order of a second or so) between each initial button create call. The purpose for this is to spread in time the initial draw of each inage button. Each gif image requires around 12k of RAM while it is decoding (which it does on each draw unless cached). This test is to see if it is a low memory situation while decoding that is causing the problem. Images also have a config macro that can turn on memory usage tracking. You will still need to test that memory usage however. 4. Try rebuilding your gif images with a different image editor. It is not uncommon for gif images to be "non-standard" in some fashion and while uGFX handles most of those there might be something there. 5. If that makes no difference feel free to post a zip of the minimal project. Use #if 0 macros in the source to show the effect of image reordering. We will then debug the decoder itself for you.

My guess is that while the incpath is being sent to the c compiler, it is not being included on the assembler command line.

We definitely recommend using an embedded os particularly for starter users. There are several reasons... 1. RAW32 is complex to get working in some cases due to its C compiler and/or CPU dependancies. 2. RAW32 is a co-operative scheduler. Most embedded os's will provide a proper preemptive scedular. 3. Most embedded os's also provide some sort of HAL layer for talking to standard peripherals such as SPI. This vastly simplifies talking to your hardware. 4. Most embedded os's provide a suitable c library and runtime startup code. With RAW32 you are responsible for all the startup initialisation yourself. Of course the advantage of RAW32 is that it can be slightly lighter than a full operating system. Don't be decieved however that is not always the case. For example, STM provide a HAL library that vastly simplifies using RAW32 on STM processors. That HAL library however is not light nor efficiently written. In many cases solutions using that HAL will be every bit as large as the same application using an embedded os. When selecting an embedded os the selection of available features can be very important. For example, some os's don't provide a HAL (eg FreeRTOS), some are not real time os's (RAW32 itself definitely isn't), some are only available on a narrow range of platforms, some are not well supported, some are expensive, some have restrictive licensing terms (eg GPL) etc. I think people like to write "bare metal" because they think they will end up with a simpler, more efficient solution. That is definitely not always the case and going "bare metal" can add a lot of complexity to the development process itself.

Makefiles are available to work with any compiler on any platform. Nothing else in terms of build platforms is that portable. Makefiles also work with 90% of IDE's and many internally use makefiles, including from memory Eclipse (although some IDE's use variant syntax). The reason the config variables are commented out is because that gives the best future compatibility. If it is TRUE it is definitely TRUE, if it is FALSE it is definitely FALSE, but if it is not specified then uGFX will provide a default value. Thus not specifying an option allows the interaction between the options to be safest and if we change a default in the library then when the user recompiles they get the new default. This strategy came about from experience with compatibility between uGFX versions and will be particularly important in the move to uGFX V3. As far as I know Elixpad is not available to the public (although only Joel can determine that as it is a product he is building to sell). It does not currently support code completion.

Follow the example of the other gdisp drivers. To write a new drivers you will only need a new gdisp_lld_config.h and a new driver c file. You will not need to alter any part of the uGFX source itself. Note that for uGFX V3 the driver interface will be changing. We will port your driver to the new interface (when it is ready) provided your driver has been contributed to be part of the repository. We may rely on you to test that port however.

Can you please post your GFILE ti wrapper code and we will look to add it as an official wrapper in the repository.

Our dev environment is actually a very interesting question. I started on Win32 and Eclipse, migrated to CodeBlocks for a while, tried Visual Studio, I used Keil for a while, but now I use Elixpad (an editor framework that Joel wrote). So 90% of all my dev is on windows and mostly using mingw compilers with make scripts with gcc for cross compiling. Other tools I use are the cygwin unix utils, notepad++, WinMerge and SourceTree and of course the uGFX Studio for quick prototyping. Hardware wise I run a wide range of hardware from MSP430's, STM, AT, to embedded x86. I run numerous types of screen and touch arrangements (as would be expected as a main uGFX developer). Despite all the hardware, uGFX is largely developed and debugged on Win32 using the cross platform capabilities of uGFX. Joel uses a different software mix to me and tends to run more linux than I do. Joel might like to describe himself what he uses.

This has now been updated in the master repository. As I don't use FreeRTOS myself can you please check that I got it right? Thanks for finding this and your assistance in solving it.

I suggest that in the gfxCreateThread function we should divide by sizeof (WORD) before passing it to xCreateThread. That will keep the meaning of the stack size passed to gfxCreateThread consistent accross platforms. If we do so, is WORD a defined FreeRTOS type or should we use sizeof (int) or something else? Thanks for finding this!

Personally I like the F769 board better too. The reason I suggested the F429 instead is that it is more middle of the range in computing power and accessories. The F769 is one of the faster processors in the range and therefore not as indicative of a "standard" project. I will check pricing however because if the F769is cheaper that may swing me in the other direction. Any thoughts? Joel, what do you think too?

Yes, please do share your experience. The suggestions you have are good. I will look at what we can do with binaries for uGFX v3. Perhaps we will select one or two platforms as our "binary" platforms. Perhaps Win32 and STM429I-DISCOVERY? The reason I picked Win32 is so people can run a demo with no hardware and is the most commonly used dev environment. The reason I picked the STM429I-DISCOVERY is because it is cheap, common, and uses STM32 chips which currently seem to be the most commonly used range of cpus in the community. Comments anyone?

1. That behavior is reasonable. uGFX is designed to be small so does not do a lot of parameter checking. Sending a negative width is actually a user program error and so a resulting crash is definitely possible. 2. We will look into this.

That looks about right. My expectation would be SPI x 2-4 = 8bit, 8bit x 2 = 16 bit.

You can make an estimation as 854 x 470 x 2 bytes/pixel / 2 bytes per cycle (16 bit bus) x cycle time. Note the cycle time can be estimated from the cpu speed (allow say 20 instructions per cycle) and the maximum speed of the display controller bus. Note in practice, except for video, 300ms per full screen would be perfectly acceptable performance.

It sounds to me from the symptoms you describe that you are getting a link error. When you said that you can't see gdisp_lld_init being called it made me wonder if you have added a display driver to the project? A display driver will be required if you have enabled the GDISP module.

Thankyou Michal for your feedback and welcome to the community. There are some example projects in the downloads section but more would definitely be nice. The real issue for us is purely man power. There is still a lot we want to do with uGFX and we simply don't have enough time as it is. Also a danger with example projects is that they can get out of date. Maintaining them can be an issue. As an example I am currently working on some changes for upcoming uGFX v3. Those changes mean every example application in the uGFX source directory plus every driver needs to be updated and tested. This job alone is probably a couple of man weeks of work and uGFX v3 is not even close to ready yet. Then there is the multi-platform testing involved with the new release itself. I would love for someone in the community to take your suggestion up as a task and commit to providing and maintaining example projects (and possibly some binaries) for us. We are also looking for someone to provide help with the wiki and other documentation. Any help is appreciated.

64 bit compiling is not yet officially supported however the code has been carefully written and should be mostly compatible as you have found out. Rather than change the existing os_osx.mk let me suggest that you create a new file os_osx64.mk. That would then get used by specifying OPT_OS=osx64 in your makefile. After testing if you could submit the new file to us we can then add it as a supported platform. With regard to the double const, our code is actually correct. The warning message comes because gcc (and quite a number of other compilers) actually misunderstand the differences between a const pointer and a const structure. Ie they misunderstand the c standard (no flames here please). In practice it makes no difference as gcc implements it the way we want it to work despite issuing the warning.

Note that uGUI is nothing like uGFX. uGUI is composed on one c file and one h file so of course it is easier to include into a project than uGFX which contains hundreds. The resultant capabilities however also match that. It simply can't do a fraction of what uGFX can do.

Note: FMSC is a STM32 cpu facility that makes a block of cpu pins act as a parellel bus with programmable timings. It is not a slave device bus type but a way for the cpu to create a bus from gpio pins. It is not essential, anything that can be done with a FMSC interface can be done with gpio pins directly. It is not even necessarily faster. What it does provide is more accurate timing than gpio "bit bashing" and it (very slightly) simplifies the code to access the device at the expense of a more complicated initialisation sequence. That is, FMSC is a nice feature in a cpu but definitely not mandatory or even important.

Don't be concerned about hardware acceleration for 2 reasons; 1. You are not doing any particularly heavy graphics processing, and 2. Bus speed is typically far more important than acceleration in these types of devices. That display listed looks likely to be a good choice although there are a couple of things to check... 1. It seems to have both a SPI interface (a cpu SPI port + 2 extra cpu control pins) and an 8 bit interface. Using the 8 bit interface (12 cpu pins needed) will obviously be faster than SPI but how do you configure the display to use that inferface over the SPI interface? There may be a jumper on the lcd board to configure it. You will need to ask the manufacturer or reverse engineer it from the board traces. 2. Is that controller chip supported by uGFX (i can't currently check for you as i am on my phone).

For the purpose of the test temporarily removing (commenting out) other widgets is actually a good idea. What you are trying to do is remove as many other factors as possible to get to the source of the problem. The symptoms in this case smell of overwriting your stack space, failing a memory allocation and not testing the result, or something similar. There are really only two ways to find these sorts of problems... 1. Simplify, simplify, simplify until it works, or 2. Debug until you see the problem and then figure out why. Other things that make me think it is a stack overwrite or out-of-memory condition is your comment earlier that you have increased the heap to the absolute maximum, and the comment that if you reduce the heap size some widgets don't show. The previous posts steps were diagnostics to try and identify these types of problems.