Problem SSD1963 and STM32F4 Discovery

[TechNet]

Hi,

I have lately bought LCD panel like this http://www.ebay.com/itm/7-TFT-LCD-Modul ... 0963914141 but I can't make it work properly . The image is completly jagged. I rode this topic http://forum.chibios.org/phpbb/viewtopi ... =11&t=1133 but it didn't help. Panel is connected through 20 cm wires. I'm using FSMC.

My gdisp_lld_panel.h

Code:

/*
 * This file is subject to the terms of the GFX License. If a copy of
 * the license was not distributed with this file, you can obtain one at:
 *
 *              http://chibios-gfx.com/license.html
 */

/**
 * @file    drivers/gdisp/SSD1963/gdisp_lld_panel_example.h
 * @brief   TFT LCD panel properties.
 *
 * @addtogroup GDISP
 * @{
 */

#ifndef _GDISP_LLD_PANEL_H
#define _GDISP_LLD_PANEL_H

/* LCD panel specs */

/* The timings need to follow the datasheet for your particular TFT/LCD screen (the actual screen, not the controller)
*** Datasheets normally use a specific set of timings and acronyms, their value refers to the number of pixel clocks
** Non-display periods refer to pulses/timings that occur before or after the timings that actually put pixels on the screen
** Display periods refer to pulses/timings that directly put pixels on the screen
HDP: Horizontal Display Period, normally the width - 1
HT: Horizontal Total period (display + non-display)
HPS: non-display period between the start of the horizontal sync (LLINE) signal and the first display data
LPS: horizontal sync pulse (LLINE) start location in pixel clocks
HPW: Horizontal sync Pulse Width
VDP: Vertical Display period, normally height - 1
VT: Vertical Total period (display + non-display)
VPS: non-display period in lines between the start of the frame and the first display data in number of lines
FPS: vertical sync pulse (LFRAME) start location in lines. 
VPW: Vertical sync Pulse Width

*** Here's how to convert them:
HPS = SCREEN_HSYNC_PULSE + SCREEN_HSYNC_BACK_PORCH
HT - HPS = GDISP_SCREEN_WIDTH + SCREEN_HSYNC_FRONT_PORCH
=>    SCREEN_HSYNC_FRONT_PORCH = ( HT - HPS ) - GDISP_SCREEN_WIDTH
   SCREEN_HSYNC_PULSE = HPW
   SCREEN_HSYNC_BACK_PORCH = HPS - HPW
   SCREEN_HSYNC_PERIOD = HT

VPS = SCREEN_VSYNC_PULSE + SCREEN_VSYNC_BACK_PORCH
VT - VPS = GDISP_SCREEN_HEIGHT + SCREEN_VSYNC_FRONT_PORCH
=>   SCREEN_VSYNC_FRONT_PORCH = ( VT - VPS ) - GDISP_SCREEN_HEIGHT
   SCREEN_VSYNC_PULSE = VPW
   SCREEN_VSYNC_BACK_PORCH = VPS - LPS
   SCREEN_VSYNC_PERIOD = VT
*/

#define SCREEN_FPS 60ULL


#define GDISP_SCREEN_WIDTH 800
#define GDISP_SCREEN_HEIGHT 480

#define SCREEN_HSYNC_BACK_PORCH     46
#define SCREEN_HSYNC_FRONT_PORCH    210
#define SCREEN_HSYNC_PULSE          8

#define SCREEN_VSYNC_BACK_PORCH     23
#define SCREEN_VSYNC_FRONT_PORCH    22
#define SCREEN_VSYNC_PULSE          8


#define   SCREEN_HSYNC_PERIOD   (SCREEN_HSYNC_PULSE + SCREEN_HSYNC_BACK_PORCH + GDISP_SCREEN_WIDTH  + SCREEN_HSYNC_FRONT_PORCH)
#define   SCREEN_VSYNC_PERIOD   (SCREEN_VSYNC_PULSE + SCREEN_VSYNC_BACK_PORCH + GDISP_SCREEN_HEIGHT + SCREEN_VSYNC_FRONT_PORCH)

#define SCREEN_PCLK   (SCREEN_HSYNC_PERIOD * SCREEN_VSYNC_PERIOD * SCREEN_FPS)
#define GDISP_FPR      ((SCREEN_PCLK * 1048576)/100000000)

#endif
/** @} */

Some photos:

1. Image demo

2. Text demo

3. Basics

Please don't look at the colors, I have fixed them (RGB to BGR). But I still have pixels in random places or I haven't in other (for example ragged diagonal line or multicolored lines on right side on third image ).

LCD datasheet is available here: http://propix.com.pl/pl/p/file/ec1058c5 ... 2_PV02.pdf. Please help me with it.

PS. Sorry for my bad English.

[resset]

I had similar issue on different driver. Please check how do you initialize FSMC, especially BTR register. The reason of such behaviour can be too short delays introduced by FSMC. For instance, I'll show you how was it in my case (STM32F4):

This was losing/misplacing pixels:

FSMC_Bank1->BTCR[FSMC_Bank + 1] = (FSMC_BTR1_ADDSET_2 | FSMC_BTR1_ADDSET_0) \
		| (FSMC_BTR1_DATAST_2 | FSMC_BTR1_DATAST_0) \
		| FSMC_BTR1_BUSTURN_0;

And this works OK:

FSMC_Bank1->BTCR[FSMC_Bank + 1] = (FSMC_BTR1_ADDSET_2 | FSMC_BTR1_ADDSET_1) \
		| (FSMC_BTR1_DATAST_2 | FSMC_BTR1_DATAST_1) \
		| FSMC_BTR1_BUSTURN_0;

The reason may also be too long wires, but I'm not expert here.

[TechNet]

Now it works! Thank you resset! I have only changed these FSMC dealys.

EDIT: But I still have three multicolored lines on right side

[Joel Bodenmann]

Good to hear that you got it working.

The multicolor lines indicate that this part of the screen was not initialized properly. Please check your initialization code to make sure that the entire area gets initialized.

~ Tectu

[TechNet]

I have changed this

/* Screen size */
	write_index(SSD1963_SET_GDISP_MODE);
//	write_data(0x0000);
	write_data(0b00011000); //Enabled dithering
	write_data(0x0000);
	write_data(mHIGH((GDISP_SCREEN_WIDTH+1)));
	write_data((GDISP_SCREEN_WIDTH+1));
	write_data(mHIGH((GDISP_SCREEN_HEIGHT+1)));
	write_data((GDISP_SCREEN_HEIGHT+1));
	write_data(0x0000);

to this

	/* Screen size */
	write_index(SSD1963_SET_GDISP_MODE);
	//write_data(0x0000);
	write_data(0b00011000); //Enabled dithering
	write_data(0x0000);
	write_data(mHIGH((GDISP_SCREEN_WIDTH-1)));
	write_data((GDISP_SCREEN_WIDTH-1));
	write_data(mHIGH((GDISP_SCREEN_HEIGHT-1)));
	write_data((GDISP_SCREEN_HEIGHT-1));
	write_data(0x0000);

and it works perfect. However I wolud like to use 18 bit color, but when I turn it on I get red color instead of black. On 16BIT565 everything is fine.

[Joel Bodenmann]

One more issue fixed - excellent! I will try to come up with a better solution for custom initialization routines.

When you want to use your display in 18-bit mode, you have to create a copy of the driver and modify it that it matches the 18-bit stuff. The current SSD1963 driver runs in RGB565 format. You have to make sure that you handle all the colors and data writing correctly inside the driver.

You will also have to redefine the color_t type since it's a uint16_t by default.

~ Tectu

[mobyfab]

Hi,

The initialization code is fine, you need to fix (decrease) the front/back porch on your panel file instead.

Also note that you cannot use FSMC for 18 bit pixel depth.

[TechNet]

Hi mobyfab,

On 16 bit evertyhing works fine, but I tried to run 18 bit. Why it isn't possible on FSMC?

[Joel Bodenmann]

Because the FSMC has per definition only a 16-bit data width. You'd have to bitbang your stuff using GPIO then.

@ mobyfab: There are an awful lot of people having issues with the SSD1963 driver. Can you confirm that the driver itself is fine the way it is and that it's only a problem with the panel configuration? We have to find a solution for this. Maybe some more documentation will help there.

~ Tectu

[mobyfab]

I will look into in when I have enough time.

However in this specific case there is nothing wrong with the driver, just the panel file uncorrectly setup.

The SSD1963 driver will always be troublesome as everyone has different panels, we'd need lots of panel files (and test them) to get something that works out of the box.

Forget about anything more than 16 bits as the FSMC and GPIO buses are 16 bits on STM32.

[Joel Bodenmann]

Forget about anything more than 16 bits as the FSMC and GPIO buses are 16 bits on STM32.

Well, it can be done with GPIO without any problem. Since he uses ChibiOS/RT it's fairly easy because it offers to build a bus structure out of several GPIO pins. However, I don't really see the reason to use this display in 18- instead of 16-bit mode too. I don't think that you'll notice any difference at all.

~ Tectu

[mobyfab]

I mean it would be really slower.

[Joel Bodenmann]

Yes, that for sure, I also meant that you won't notice any visible color quality differences

~ Tectu

[inmarket]

Perhaps Tectu or Mobyfab would like to put together a readme on common problems someone might see with this (or similar) drivers and the steps that can be looked at to address the problems.

TechNet supplied images as part of his discussion which made it obvious to the experts mobyfab and Tectu what might be happening. Similar images in a readme would help other users to self-diagnose their new panel.

[dimky]

Hey TechNet!

Could you please share your project running stmf4discovery + ssd1963?

[TechNet]

Hi dimky!

Unfortunately, I stopped working on this project over 1,5 month ago. Now, I see that there is a huge mess in files, so I think it won't help you

But you can decribe your problem here and we would try to help.

[dimky]

I just can't make start project.

Chibios works fine using keil. But I can't add uGFX because keil is not compatible with makefiles so there is a big problem with adding all necessary files and paths for it.

When I'm trying to create project in eclipse, I have blank window after I selecting project type.

I also tried ChibiStudio, but when poject is created, it is not listed in "Project explorer"...

[TechNet]

Did you read this tutorial http://www.chibios.org/dokuwiki/doku.php?id=chibios:guides:eclipse2 ? I created my first programs in ChibiStudio using makefile and demo projects.

[Joel Bodenmann]

I strongly suggest you to take the working ARMCM4-STM32F407-DISCOVERY demo which comes within ChibiStudio and start modifying it from there.

~ Tectu

[dimky]

Okay. But how to upload compiled project using ChibiStudio?

[Joel Bodenmann]

Please read the guide which already has been linked.

~ Tectu

[juppeck]

Hello,

i would like to add some lines to the FSMC and Display connectivity. At first, i wondering why the GCC Compiler is prefered to use in combination of the worst IDE like "Eclipse" and their commons. To get the IDE works with the JTAG and the Environment Setup is done, a couple of hours could be passed. For a beginner in Cortex-M programming, the homogene IDE like µVision from Keil make the start easier.

The next Point, same reason is the use of the CMSIS-Library and Std-Library instead Manipulation the bits directy. You must beware about the huge amount of available Registers and their names. A good example that demonstrate what i mean is the FSMC init Structure that Needs to be filled with valid Parameters. Every Screw thats required to be turn should be self described by a regular name.

This example do a part of the FSMC Setup by using a structure to map the FSMC lines. Looks very understandable, or not ?

GPIO_PinAFConfig ( GPIOD, GPIO_PinSource9, GPIO_AF_FSMC ); // D14 // GPIO-PortD Pin9 will used as FSMC

GPIO_PinAFConfig ( GPIOD, GPIO_PinSource10, GPIO_AF_FSMC ); // D15

GPIO_PinAFConfig ( GPIOD, GPIO_PinSource11, GPIO_AF_FSMC ); // A16 // use Address A16 as /RS of Display

GPIO_PinAFConfig ( GPIOD, GPIO_PinSource14, GPIO_AF_FSMC ); // D0

GPIO_PinAFConfig ( GPIOD, GPIO_PinSource15, GPIO_AF_FSMC ); // D1

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_4 | GPIO_Pin_5 | GPIO_Pin_7 | GPIO_Pin_8 | GPIO_Pin_9 |GPIO_Pin_10 | GPIO_Pin_11 | GPIO_Pin_14 | GPIO_Pin_15; // i will use this PortPins to setup

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF; // use the alterative pin function

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz; // 100Mhz Clock of I/O Flip-Flop

GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; // I/O Output will be Push-Pulled

GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; // no Pull-up or Pull-Down Resistor used

GPIO_Init ( GPIOD , &GPIO_InitStructure ); // and finaly i will init the GPIO-Port D with my setup structure.

i don't understand why many programmers prefere to use the old school bit names and their maniplation like this:

FSMC_Bank1->BTCR[FSMC_Bank + 1] = (FSMC_BTR1_ADDSET_2 | FSMC_BTR1_ADDSET_1) | (FSMC_BTR1_DATAST_2 | FSMC_BTR1_DATAST_1) | FSMC_BTR1_BUSTURN_0;

Is line this understandable without a Manual, that further describe the register Function and bit Position. Understand me right - there is nothing wrong to do like this - the final result of the preprocessor of both methodes looks equal. The code result would be similar because both are just preprocessor definitions and declarations. So, it's easier to understand what you had programmed and finaly set, if the CMSIS Lib is used instead direct bit Manipulation.

[Joel Bodenmann]

Hello juppeck

At first, i wondering why the GCC Compiler is prefered to use in combination of the worst IDE like "Eclipse" and their commons. To get the IDE works with the JTAG and the Environment Setup is done, a couple of hours could be passed. For a beginner in Cortex-M programming, the homogene IDE like µVision from Keil make the start easier.

I agree with your statement that a homogene IDE such as Keil is a lot easier for beginners. I don't use Eclipse myself and I never understood why especially all the beginner tutorials seem to use it as it is rather difficult to set up.

However, Keil and other proprietary IDEs are not popular with beginners and DIY people as they have either a built-in size limit or are expensive (usually both). And when working with a graphics library such as µGFX, 32kB binary size really is not much.

Note that µGFX itself has no such thing as 'prefered Compiler' or 'prefered IDE'. We spend a lot of time and effort into keeping uGFX free from any IDE or compiler bindings. In fact, that seems to be one of the reasons why µGFX is so popular with commercial and DIY users. It is true that most of our DIY users are using GCC but this is simply due to the fact that it is free to use without any restrictions. Some of those users are either using the Makefile based system, Eclipse or CoIDE, now Em::Blocks seems to become popular as well.

Commercial users on the other hand seem to usually use either Keil or IAR, both of which work just fine with uGFX as well.

The next Point, same reason is the use of the CMSIS-Library and Std-Library instead Manipulation the bits directy. You must beware about the huge amount of available Registers and their names. A good example that demonstrate what i mean is the FSMC init Structure that Needs to be filled with valid Parameters. Every Screw thats required to be turn should be self described by a regular name.

Same as above: uGFX is held generic. It is not bounded to any underlying library. Therefore you can use whatever you like.

It is true that most of the example board files are ChibiOS/RT specific. The FSMC line that you posted comes from a ChibiOS/RT usage examples from quite a long time ago. Replacing it with your suggestion (which is indeed more readable) would force the user to include the Std-Library in the ChibiOS/RT settings which adds a huge overhead.

As a summary: You can use whatever you want and we don't expect you to face any issue. If you are having difficulties using a specific IDE or compiler, please let us know as we are interested in removing these kinds of boundaries

~ Tectu