inmarket

I can see the problem. I will fix it today. like you said, I missed a break. Sorry.

A compiler warning with GWIN Tabsets is now fixed.

The Mikromedia-Plus-STM32-M4 board has been added thanks to work by lliypuk. Development on this board is not complete and there are likely to be frequent updates over the next few weeks. Currently the board should support display, touch and audio (although audio has not been tested).

Changes to the SSD1963 driver have been made to hopefully make it more compatible with new boards. Those with existing hardware using this driver should test it with the new version and report any problems.

The STMPE610 touch driver has been added thanks to work by lliypuk.

The STMPE811 driver has had its self-calibration capability updated to work correctly on orientations other than GDISP_ROTATE_0

I finally got an opportunity to try the Mikromedia-Plus-STM32-M4 code. I have added the code now to the master repository (with changes). I have some interesting results: The display code that you had wouldn't work for me. There was simply no display at all. Reverting to the standard SSD1963 code worked for me and I had none of the flicker issues that you had. It was rock-solid. I have tried to integrate your code as much as possible whilst still maintaining a working driver. You will see I have defined SSD1963_INIT_METHOD_2. If set in the board file it will use your code (with some mods). Without it, it uses mostly the old code. I have not tried other orientations, changing the backlight level or contrast although I fixed a couple of obvious problems. I will write a test utility specifically for this so that all the drivers can have these functions more easily checked. The touch driver is not working correctly in self-calibration mode. I will need to do more work with this. I have not tried the ugfx audio on this board yet. I have not tried any other hardware (non-ugfx related eg Ethernet, sdcard) yet. My board is labelled V1.02 (just below the SD-Card and above the 2.4G transceiver. Can you please try the latest repository code and let me know how you go. I am particularly interested in any changes you have subsequently made to your source, any changes to the ChibiOS files and how the display driver works for you. Please also let me know what hardware revision your board is. Thank-you for your great help.

When GFILE_NEED_STDIO was set to TRUE there were a couple of sources of compile errors. A/ There were definition conflicts within the stdio emulation routines themselves. B/ A number of GOS emulation layers (eg Win32, X) and supporting drivers require access to the native platform stdio.h file. When GFILE_NEED_STDIO was defined this lead to definition conflicts for these platforms. Both these issues are now resolved.

Setting GFILE_ALLOW_FLOAT to TRUE would generate a compile error. This is now fixed.

Both these compile bugs should now be fixed.

Thanks for finding the bug. Code gets changed and we don't always get to test every code option. I will fix it in the master repository in the morning (too late for me now). Using sprintg is probably the best way to get a float value into a label. Given that you have found this problem it looks like you were heading that direction anyway.

Thank you very much. I will incorporate that into the master when I integrate the board. I will see if that is the issue with the stm32429-idiscovery board as well. You are a genius!

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.