inmarket

Anytime that changing the optimization level changes the output - that indicates a bug in the compiler optimiser (or atleast an inadequacy). While we try to write code to avoid common optimiser bugs, uGFX supports many compilers and we can't cover every optimiser bug in every compiler. Unfortunately as a result we always suggest compiling only with basic compiler optimiser settings ie -O0 or -O1. -O2 seems to work on some compilers but not all.

The two GDISP_SCREEN_XXX macros are pretty much obsolete. They may be used inside a driver to initialise the display size eg Win32 but that is not required. What is important is the setting of the g->g.Width and g->g.Height members in the gdisp_lld_init routine. Once initialised there is no api support for changing the resolution thereafter although something could be coded using a special GISP_CONTROL code. You would however need to be very careful with framebuffer reinitialisation and things like that.

It sounds like you want the full power that X (with or without Qt) can provide. Unfortunately that doesn't come without resource cost. uGFX obviously doesn't come with all those features but it also doesn't come with the same resource cost either. The same will apply for whatever system you use - it is always a compromise between the features you want and the cost of those features. BTW, video is posdible with uGFX particularly using our streaming API. It just won't be as efficient as the GPU decoding and displaying the video directly. Even using GPU for decoding, tranfering to CPU RAM and then streaming will add overhead. You could however use uGFX to reserve a window area and then use GPU decoding and rendering within that window. Whether that is worthwhile or not depends on the resource issues that your application requires. Note that no windowing system other than X will allow you to use the GPU on the raspberry pi. That is because that is the only aolution that the closed source GPU driver has been made available for although I believe there are efforts being made to reverse engineer how it works.

Yes, what Joel said is correct. We are happy for any contribution at any level. I am happy for either V2 or V3 contributions. V3 contributions are easier for me as I don't have to port the type names etc to V3 but they will obviously not be available for most users until V3 is released. V3 currently compiles for Win32 to the point where it can run the basics demo. Most of the rest of GDISP is broken as it hasn't been ported to the new driver interface. In fact some of the finer details of the V3 driver interface are not settled yet eg. Whether the driver or the gdisp layer updates the window cursor (currently the driver). If you are interested I would be happy to talk to you outside of the forum on the design aims and efficiency comprimises that are being made there. I am currently in the process of moving display orientation support from the driver into the gdisp layer and introducing the concept of a scan direction for the driver. This will enable orientation support on all displays with better efficiency for those that support scan direction changing. Win32 will remain the only driver capable of running V3 until the interfaces are finalised. I tend to try and leave the V3 repo in a compilable state (although currently only for the basics demo) so if you are feeling brave you are welcome to try it. Once I have the GDISP low level layer finalised (anything that needs to take the driver lock) there will be lots of work porting drivers etc and any extra man power would be highly appreciated. Any new features that don't require GDISP low level code are also very much appreciated. As an example I have a bunch of code with new trig highly efficient trig api. That needs to be tested and integrated and V2 compatibility thunks added but obviously the new driver interface is currently taking priority. However you would like to help or contribute we would be very glad.

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.