inmarket

Not easily. Double buffering is never easy.

No need to write something new. In your main loop before calling geventWait you can obtain the mouse source and attach it to the listener. That way you will get a copy of all mouse events and you can find when it is pressed over the graph. As an example look at code in the touch test tool (under the tools directory).

We will add that line to the current repository. Thanks for finding it. Note this is a board level change not a driver change and there is a good chance the same or similar bug exists in other board files that use the same driver. I will check and fix as necessary. Adding a define to use or not use external sdram is not necessary as a board either does or does not use external ram. It is the board file that encapsulates that. If you change the physical board to remove the external sdram then the board file needs to change too. As the stm32fxxc-discovery boards tend however to be used as examples I will add documentation to the board files to indicate what must be done for that type of physical change. Thanks for your good work on this.

There are 2 problems... 1. Your include path is not correct. That is causing the messages about the missing .h files. I suspect the board directory is not on your include path as that is where I would expect those files to be found. 2. That board file is a chibios specific one. The SPID5 is a symbol defined by chibios. You will need to update the code to use the cubemx equivalent. I thought someone had already done an example for the 429 discovery board for RAW32. Check the downloads area.

Make sure you do a make clean. Adding that one line should have caused a compile error as img1 would not be defined. As you are not getting that error message something is going wrong with the build - hence the comment above about doing the make clean.

uGFX uses the underlying operating system to handle it's threads - in your case linux. uGFX puts a very thin wrapper around it just to make the API consistent across OS's. Creating a stack variable in one thread and using it in another thread is no problem at all provided the original stack frame is still valid ie you haven't returned from the function that allocated the stack variable.

1. gdisp_draw_pixel does not use DMA2D because it is much slower than simply getting the CPU to do it. DMA reduces CPU cycles for larger transfers but the overheads of the setup are larger than the performance gains when you are setting a single pixel. 2. Unfortunately I don't know the answer to this. Reading the spec sheets should answer the question.

If the controller supports a pixel addressable window (rather than a 3 pixel addressable window) it should be possible to not use a framebuffer even without read back. A similar example is the nokia-ge8 driver which uses 12 bits per pixel and requires pixels to be written in pairs. It also allows a single pixel addressable window but wraps the extra pixel if you specify an odd pixel length. It also has other orientation bugs that definitely make it the strangest driver.

1. Already included in V3 at least for GDISP and his stuff. 2. For v3.0 V2 compatibility will be on, it will be turned off by default in a later 3.x release. 3. Consts are added where we find they should be. Note that the example given, if you are talking about the gwin parameter, it shouldn't be const as the gwin object may need to be thread locked which may require altering the lock on the gwin object. Just because the current implementation doesn't modify the structure, the API definition still needs to allow that it might. If you have specific examples where consts are missing (other than as legitimate API definition) please let us know. 4. There are code size implications for including all functionality and distinguishing it with flags. In some cases we have done that but as you say we have not been consistent largely due to slightly different methodology by different programmers. Some of these decisions will be reexamined when gwin is reviewed later. Custom draw routines however are very intentional. They provide a great way of custom extending drawing behaviour with little code and can be nested to provide "subclassing" style functionality. 5. The button should not be extended to have a toggle function as the button is designed to be momentary only. The checkbox is the state toggle widget. What confuses most GUI programmers from other platforms is the widget name which raises expectations of appearance. In uGFX the custom draw enables the presentation to be seperated from the functionality. There is no need to duplicate toggle functionality into the button widget thus saving much code. 6. Good idea. 7. Also a good idea but it is a lot of work as we hand designed UI1 and UI2. 8. Good idea. One disadvantage is that we currently build the font files from public font binaries (other than UI1 and UI2). That would no longer be possible if we add defines to control language inclusion. We would also need to pick a few common subset languages to add defines for. 9. This is difficult without either a method to store arbitrary object shapes and their drawing order (ram intensive) or support for overlapping windows. Again the gwin review will look at the end of those two approaches. 10. The gwin vmt address can be used for this purpose however these const values are not currently exposed publicly but can be derived imperically from existing objects eg at object creation. 11. Good idea 12. This will come with time. 13. Interrupt events are nice for responsiveness but are difficult at an os level due to restrictions on what can be done in them. They are also extremely non-portable, both at an operating system level and at a cpu level. Additionally there are also priority problems on some platforms. uGFX has therefore been designed to not require interrupt handling. It can however be used in some situations to improve responsiveness eg in gaudio and touch drivers. The toggle driver subsystem is very old (one of the oldest) and probably needs a review pass. This may or may not happen as part of the V3 driver changes but only if it is required for V3 toggle drivers to work (just due to time).

PS. In case you are wondering the new API's are not ready to share yet as they are still in flux. Later on we may also call for assistance in converting existing drivers or module code to the new internal APIs. If anyone would like to volunteer (and get pre-release access) then please let us know. We will then contact you when we are ready.

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_...