inmarket

I will look at it in the next few days. The stm32429-idiscovery board has the same problem based on the symptoms you describe. It is time I got to the bottom of it. I suspect the problem is not purely the back light but rather the way halftone colors are multiplexed on the display. It is interesting to note that the demos supplied by the manufacturers tend to use mostly saturated colors. I suspect that this is an attempt to hide a flaw in this type of controller or display. I will know more when I get time to do some more debugging. PS. The Mikromedia STM32 board (without the plus) does not have this problem but it uses a different controller chip. The change in controller chip for that board occurred sometime after the initial release so perhaps it was to fix to related the same problem

Dma is likely to be slower than gpio bit banging although it will use less cpu. If you want best update speed don't use dma. If you want lowest cpu load then use dma. Dma is really also only of value for large writes as there is extra overhead in setting up the dma. Occasional writes are also better than continuous writes with dma as if the dma is busy when you come back to write more the cpu ends up busy waiting for it anyway. For these reasons dma is often not the advantage it would at first appear. A situation where dma would be very useful is in video display. The writes are occasional (one write per frame), they are large (the full display area) and the cpu can make use of the extra time in decoding the next frame.

Thank you very much. That has saved me a bucket load of time. I will do some testing at the first opportunity and then integrate the code back into the master repository. Well done!

From the looks of this the individual pins are being toggled correctly. It looks like the bus definition however is not working and therefore no data is getting to the display. Can you please check the chibios bus definition api calls and verify that the code Tectu provided is correct In that area. Unfortunately we can't be experts at everything and the chibios bus definition are not something we regularly use. The chibios forum may also be able to help in this area if you get stuck. Once the data lines are toggling, if the display still doesn't work then please add another post here. When doing your testing it would be useful to use a demo that is constantly updating the display. Try using the gdisp/streaming demo as it should keep the display pins very busy.

Unfortunately other things have intervened and I have not completed support for this board yet. I will get back to it and try and get it done over the next week or so. From memory the drivers are largely supported but the board is not yet supported in chibios. It was the chibios specific stuff that was taking the time.

It looks like from the number of pins connected in the photos that you are using perhaps a SPI interface to talk to the display? Can you please send the connection diagram between the board and the display, and a copy of your current board_ILI9325.h file.

Just one small thing I noticed... The board file you have listed is the chibios board file. This file should not be altered (usually). The file you have called "driver_ILI9325" should be called "board_ILI9325".

Previously it was difficult to get a clean arrow head on a button when using the arrow custom draws. This is now much simpler as we have added support for drawing arrow heads with 45° angles. This is now the default. The old method can still be achieved by altering the drawing parameters at the top of gwin_button.c An arrow symmetry bug has also been fixed. This post is related to the issue: viewtopic.php?f=9&t=154

Our user "Dmitry Vorobyov" brought an issue with the arrow rendering of the buttons to our attention with his pull request. It turned out that this issue was actually caused by a problem in the filling polygon drawing routine where filling a polygon and then drawing the polygon outline could lead to single pixel errors in some of the lines. This was caused by different line drawing algorithms being used by the two routines. The fix was to improve the handling of half pixel errors in the fill routine.

We have added the TLS8204 monochrome display driver to the repository. This chip is used in typically 84x48 pixel displays such as the Olimex MOD3310 display. We also fixed a number of other monochrome drivers during our testing of the new display.

It looks like fonts and filled circles are problematic. Tomorrow I will send a graphic of what the circles demo should look like. This is definitely strange. Can you please post your board file? From the pictures it looks like pixel setting and bitmap operations are working fine but there may be a problem using fill or line operations. In particular, horizontal single pixel lines are being displayed vertically instead. The gdisp_SSD2119_config.h file contains the various operations your video controller supports. Perhaps you have a chip where one of the operations is broken. I will also look tomorrow for which of the settings you can try turning off that might fix the problem.

The FSMC speed is highly likely to be the problem given what we are seeing in the pictures. Follow Tectu's advice above and try that first as that may fix the problem with no other work.

Looking at your blink thread, you are doing a couple of wait's inside a kernel locked region. That is a definite no-no. make sure there are no sleeps inside the lock/unlock pair and try again.

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.