inmarket

If GDISP_NEED_MULTITHREAD is set to TRUE in your gfxconf.h then ugfx is fully re-entrant. Just use the standard gdispDrawStringBox or any other gdisp or gwin text api call on any thread and it all should just work. If you are looking at a simple way to periodically update something in the background, have a look at GTIMER which can provide a callback (automatically on another thread) either one - off after a delay or periodically.

Send us your code when you are done. If I can generalise it so it works with other image formats too, that will be very interesting. Keep up the good work!

Pixmap can be used to cache anything you want to draw on it including images (bmp, gif etc) or lines, text or anything else. The pixmap image call is to enable you to save the pixmap to a file as a native format image and other such image related purposes. The gdispGetPixmapBits call is the one normally used to get the display surface when you are ready to transfer it to the real screen. Note that pixmaps are much more efficient and faster than even image caching.

Have a look at the new pixmap functions and demo that were added to the master just today. Whilst images support caching in ugfx, it basically caches the whole image frame or nothing. Pixmap will probably be a much better fit for what you want.

Thank-you for this excellent contribution. I will integrate it (possibly with a few minor changes) into the master repository over the next week or so. Unfortunately this doesn't meet the requirements for the competition which is really about the GWIN widget set. We would however be very interested in your ideas for a new competition. Please post your idea's in this thread http://ugfx.org/forum/viewtopic.php?f=25&t=123

Ugfx doesn't currently support drawing to an off-screen pixmap. There is a work around however that will enable this to be done. ugfx supports multiple displays. It would be possible to create a board file for the framebuffer driver for the off-screen pixmap and treat it as if it was a secondary display. If you set the pixel format of that pixmap to match your real display you can then use gdispGBlitArea to transfer that to your real display. Using the new dynamic driver registration api it would also be possible to do this at run - time. In fact it is our intention to eventually add an api for creating off-screen pixmap drawing using exactly this method. Unfortunately this is however lower on our agenda so if you go to this extent please contribute it back as it would be useful for the community.

I am not sure I am reading your problem correctly but I think you are saying that the gfxMount fails because the driver is already active and it tries to initialise it again. If that is correct, look for where the driver is being previously initialised in your code and disable that piece of code. GFILE assumes that it is the one that is going to be initialising and controlling the block device driver

No problem. We are here to help.

Optimization can definitely be a problem. I am not sure it is the problem in this case though. Easiest way to check is to simply turn off all optimisation and do a full build. GCC in particular has some bad optimization bugs.

Wow! Now that is nice! Very good work indeed and it is interesting the techniques you have used to make it work. Can we reference your video on our demo page on the website? Also, are you looking to turn it into a commercial product or is this a hobby project?

I just had a thought - have you seen the audio and/or the gadc demos. They similarly define a scope widget (although very basic) which demonstrates another way of doing it without a full frame buffer or even the ability to read pixel ram. It would be interesting to compare the approaches. At the time I was developing on an Olimex SAMEX256 board with a Nokia6610GE8 display (a slow display with no pixel read capability).

Thanks for the description. Very interesting! Unfortunately I don't have that hardware so I will await a video.

The master has now been updated. Set the define GDISP_NO_DMA_FROM_STACK to TRUE in your board file to tell it to use main memory instead of stack space for the define. By the way, why are you using main ram for a framebuffer? Ugfx should work without a framebuffer for the SSD2119 controller.

Yes interesting problem. Removing the local variable means that the translation from user pixel format to driver pixel format doesn't occur. This ok if the pixel formats are the same (your case) but is not ok generally. There is however a simple solution - make c a static variable. This can also be conditioned on the use of dma, and optionally a define indicating the use of ccr memory. I will make the change to the master to reflect this (and in other drivers the can use dma too)

These have been updated to the latest master. Can you please test the latest master.

Yes you are 100% correct. Board files are always meant to be tweaked for the specific hardware and cable lengths etc to displays are often a critical factor. In terms of initial settings, what tends to happen is that we (or someone else from the user base) gets a board file working on their hardware. That is then posted as the "reference" board file and it is only when someone else complains about it not working that it may be re - examined. The main reason we don't perform a testing of conservative settings etc is just time. With ugfx there is just so much to do and Tectu and myself fit this around our normal work lives. In many cases we don't own the hardware as the driver/board files have been donated by a user (although I like to do a quality pass over the code before it makes the master repository). It is for this reason that we so highly value your contribution in fine tuning these parameters to work on a much wider range of hardware. Without efforts such as yours ugfx would not be usable by a wide enough base of users. Thank - you. Your changes should make the master repository in the next few hours.

Thanks. I will integrate these changes asap.

Thanks for your work on this. Can you please post your updated board files and we will integrate the changes into the master repository? Also the mouse testing, was that done against the current master. We have completely rewritten the mouse sub system since your previous post in June. The new system is much more tolerant of bad data and transitions. The work you have done with frequency of the busses is fantastic and will be very helpful in getting great results. Thank you for your hard work.

Thank you. We will correct that asap.

Thankyou. We will fix it immediately.

There are a few reasons that the font files are currently in c files rather than h files... Historically it has just always been done this way The font generator generates a c file and to alter this would require changing old and fragile code (I am not sure we can even still compile the mcufont font generator utility) None of these are really good reasons, it however just takes time to change these things and the effort involved has been very low priority considering the other work that we want to get done. Note: this is not the only place in uGFX that c files get included into other sources rather than being compiled directly. Other places this happens include where we are incorporating third party code into uGFX such as FATFS. Doing it this way allows us to leave the original code unchanged and "patch" necessary changes into it using macro definitions from the file including the source. Unfortunately, other than directly modifying the third party code (which may create license issues) this is the only way this can be done. Although using the IDE to directly "build" the project is possible - it is not our supported configuration. Our supported configuration is using a "custom makefile" project. This avoids all of these sorts of dramas. Source files can then be included into the IDE without them affecting the build process. As proof of this, more than 30% of my development of the uGFX library itself is done using Em:Blocks (the other 70% is using the Eclipse IDE or the command line). The original source of this thread related to an IDE that supposedly could not do custom makefile builds. That particular situation is still being investigated.

It is not a bug so much as a difference in how the display is spoken to via a 16 bit interface versus a 8 bit interface. The code you have changed is correct for a 16 bit hardware interface but will break an 8 bit bus interface. The code has previously only been used on such chips with an 8 bit processor interface. This driver is currently used successfully as-is on such boards as the Mikromedia STM32m4 board (which use an 8 bit cpu interface for the display). Note that changing the bus interface width may also require changing some of the initialisation code to ensure the controller expects 16 bit wide data. I will re-examine the code for the driver. It should be possible to define a MACRO that specifies 8 or 16 bit bus width and to alter the code correspondingly. Can you please post your board file and your (modified) driver file and I will build an integrated solution for the master repository so we don't break boards that are using it with an 8 bit bus.

One more thing to try if you must use the chibios supplied makefile... try changing the direction of the slashes in your absolute path to forward slashes.

I suspect you are running into a problem with make under windows. Depending on the version of make you are using it struggles to handle Dos style paths like c:\... The way around this is to try using one of our example makefiles rather than a chibios based makefile. These makefiles can be found in /boards/base/xxx/example. We have spent considerable effort trying to get the makefiles working properly under win32. The chibios supplied makefiles don't work properly under win32 using absolute paths. Please also read our wiki article on your first project in win32. One other bit... Make sure you are using the latest master as we found bugs in our makefiles as late as last week to do with absolute paths under win32

It looks like your GFXLIB define in your makefile (describing the location of the ugfx directory) is not correct. I suspect that is why you get the permission denied errors - it just cannot find that directory Similarly the "no rule to make" seems to indicate the same thing. Hope this helps. Andrew.