320x240 LCD with integrated SSD1289 controller

[Durazell]

Could someone please take a look at this and tell if there is something horribly wrong with it? Basically I'd like to use spritesmod schematic and add few leds and an IR sensor to it. Green ones in image are raspberry rev2 pin numbers.

Screen pins:
https://dl.dropbox.com/u/36296754/3.2in ... 2D_SCH.pdf

design:
https://dl.dropbox.com/u/36296754/tCad3.dsn
https://dl.dropbox.com/u/36296754/lcd.png

[Bluebox]

@XaLKiDEoS
I think i have the same one....
That pinout works for me:
http://static.electrodragon.com/wp-cont ... play-3.jpg

[XaLKiDEoS]

@Durazell
Recheck the ICs Vss and Vdd pins. The bottom left pin of the IC (pin 8 in 4094) should be gnd and top right (pin 16) is the 3.3v.

[Durazell]

@Durazell
Recheck the ICs Vss and Vdd pins. The bottom left pin of the IC (pin 8 in 4094) should be gnd and top right (pin 16) is the 3.3v.

You're right, i mistook them again .

[valdodov]

Hi guys,

I have to confess that I'm very stupid

I replaced CD4020 with CD4040 and then mismatched pin numbers
That was the reason the original SpritesMods's design doesn't work.
When I fixed this mistake everything works fine.
This is my circuit


and the result

[XaLKiDEoS]

Hi valdodov,

Thanks for sharing your schematic.
Did you use SpritesMods's kernel patch (patch -p4 < 502-ssd1289-support-linux-3.3.8.diff) with SpritesMods's ssd1289.c or the modified by notro (in this forum) ssd1289.c driver?

On the bcm2708.c for the spi0.0 I assume that you have something like this:

Code: Select all

  .modalias = "spi-ssd1289",
  .max_speed_hz = 8000000,
  .bus_num = 0,
  .chip_select = 0,
   .mode = SPI_MODE_0,

Is that correct?
May you also attach your .config file?

I cannot understand why my screen remains white. What I have done is patching the kernel, adding the SSD1289 support as a Module with SpriteMods's selection, replacing the ssd1289.c with notro's modified file and defining DEBUG and updating the bcm2708.c. Then recompiling.
After that, modprob ssd1289 shows the module's init debug info in dmesg. The screen remains white after modprob. Then I used this code to write something on the framebuffer http://pastebin.com/WhemXE2S without success. Also echo "<random chars?>" >/dev/fb1 does not print any pixel on the screen.

[valdodov]

Hi XaLKiDEoS,

I used SpritesMods's patch.

The bcm2708.c looks like:

Code: Select all

static struct spi_board_info bcm2708_spi_devices[] = {
	{
		.modalias = "spi-ssd1289",
		.max_speed_hz = 16000000,
		.bus_num = 0,
		.chip_select = 0,
		.mode = SPI_MODE_0,
	}, {
		.modalias = "spidev",
		.max_speed_hz = 500000,
		.bus_num = 0,
		.chip_select = 1,
		.mode = SPI_MODE_0,
	}
};

You can find .config file on the following link:

http://massmailing.eu/raspberri/.config

Did you remove connection to LCD's reset in SpritesMods's circuit? And did you connect it to +3.3V?

The easiest way to find out if you screen works is to execute:

con2fbmap 1 1
or
FRAMEBUFFER=/dev/fb1 startx

[XaLKiDEoS]

Hi valdodov,
thanks for your reply,

yes I tried connecting LCD reset to 3.3v directly with no luck. But all my tests had the notro's modified ssd driver as the SpriteMods's one failed on modprobe -r ssd1289. On a previous post you suggested modifing the driver to send one more dummy byte and to send byte by byte instead of block sending. With the schematic you attached you do not suppose to do these changes, correct? You just apply the patch, update the bcm2708.c file, make menuconfig to add ssd1289 as a module and make / make modules_install (do I miss something)?

I have also tried export FRAMEBUFFER with startx with no luck. I hope notro's driver update was the issue, I will do more tests using your suggestions later this evening.

[valdodov]

Hi XaLKiDEoS ,

if you find a way to remove already loaded ssd1289 module i'll be very appreciated.

You are correct. I just do:
1. Apply SpritesMods's patch.
2. Change bcm2708.c
3. Make menuconffig - chose SPI driven LCD
4. Make
5. Make modules_install
6. Reboot

[notro]

This is the diff between Spritemods patch and the version I made. It enables unloading of the driver.

Code: Select all

--- ssd1289.c   2013-03-11 14:51:28.589362371 +0100
+++ ssd1289_notro.c     2013-03-11 14:51:11.456613259 +0100
@@ -375,8 +375,7 @@
 static void ssd1289_video_free(struct ssd1289 *item)
 {
        dev_dbg(item->dev, "%s: item=0x%p\n", __func__, (void *)item);
-
-       kfree((void *)item->info->fix.smem_start);
+       vfree((void *)item->info->fix.smem_start);
 }

 //This routine will allocate a ssd1289_page struct for each vm page in the
@@ -592,9 +591,9 @@
 };

 #if defined(CONFIG_SSD1289_DIRECTIO_MODE)
-static int __init ssd1289_probe(struct platform_device *dev)
+static int __devinit ssd1289_probe(struct platform_device *dev)
 #elif defined(CONFIG_SSD1289_SPI_MODE)
-static int __init ssd1289_probe(struct spi_device *dev)
+static int __devinit ssd1289_probe(struct spi_device *dev)
 #endif
 {
        int ret = 0;
@@ -756,21 +755,28 @@
        return ret;
 }

-
-static int ssd1289_remove(struct spi_device *spi)
-{
-       struct fb_info *info = dev_get_drvdata(&spi->dev);
-       struct ssd1289 *item = (struct ssd1289 *)info->par;
 #if defined(CONFIG_SSD1289_DIRECTIO_MODE)
-       //ToDo: directio-mode: shouldn't those resources be free()'ed too?
+static int __devexit ssd1289_remove(struct platform_device *dev)
 #elif defined(CONFIG_SSD1289_SPI_MODE)
-       dev_set_drvdata(&spi->dev, NULL);
+static int __devexit ssd1289_remove(struct spi_device *dev)
 #endif
-       unregister_framebuffer(info);
-       ssd1289_pages_free(item);
-       ssd1289_video_free(item);
-       framebuffer_release(info);
-       kfree(item);
+{
+       struct ssd1289 *item = dev_get_drvdata(&dev->dev);
+       struct fb_info *info;
+
+       dev_dbg(&dev->dev, "%s\n", __func__);
+
+       dev_set_drvdata(&dev->dev, NULL);
+       if (item) {
+               info = item->info;
+               if (info)
+                       unregister_framebuffer(info);
+               ssd1289_pages_free(item);
+               ssd1289_video_free(item);
+               kfree(item);
+               if (info)
+                       framebuffer_release(info);
+       }
        return 0;
 }

@@ -836,7 +842,20 @@
        return ret;
 }

+static void __exit ssd1289_exit(void)
+{
+       pr_debug("%s\n", __func__);
+
+#if defined(CONFIG_SSD1289_DIRECTIO_MODE)
+       platform_driver_unregister(&ssd1289_driver);
+#elif defined(CONFIG_SSD1289_SPI_MODE)
+       spi_unregister_driver(&spi_ssd1289_driver);
+#endif
+
+}
+
 module_init(ssd1289_init);
+module_exit(ssd1289_exit);

 MODULE_DESCRIPTION("SSD1289 LCD Driver");
 MODULE_AUTHOR("Jeroen Domburg <jeroen@spritesmods.com>");

[valdodov]

Hi notro,

your patch works fine!
Thanks

[Aysar]

Great work, just ordered the screen and looking forward to testing it.

Just a quck questions, does your HDMI output still work simultaneously? This could be a great way to use two screens.

Aysar

[muelli]

Which screen is it exactly? There seem to be different versions on ebay...

@valdovov, could you post a link oder exact type of screen you use?

thanks!

[valdodov]

Hi muelli,

The LCD module which i'm using is:

http://www.ebay.com/itm/3-2-TFT-LCD-Mod ... 2c57cf0ce2

For thous of you which wants to see boot time messages on LCD you should modify /boot/cmdline.txt and add to it fbcon=map:1 (optionally you can specify the font fbcon=font:ProFont6x11)

[valdodov]

Hi everyone,

just to inform you that touch screen of my LCD display module works fine too.

Cheers

[Norefall]

Hi everyone,

just to inform you that touch screen of my LCD display module works fine too.

Cheers

Is there a chance that you can explain the touchscreen part a bit more in detail? How did you get it working?

Thanks! Awesome thread btw:)

[valdodov]

Hi Norefall,

of course that i'll explain.

Here is my electrical circuit:

You have to do following things:
1. You have to modify " linux/arch/arm/mach-bcm2708/bcm2708.c"

Code: Select all

#include <linux/spi/ads7846.h>

.....

#define PEN_DOWN_STATE_PIN	17

.....

#ifdef CONFIG_SPI
static int ads7846_pendown_state(void)
{
	return !gpio_get_value(PEN_DOWN_STATE_PIN);	/* Touchscreen PENIRQ */
}
static struct ads7846_platform_data ads_info = {
	.model			= 7846,
	.swap_xy = 1,
	.x_min			= 280,
	.x_max			= 3830,
	.y_min			= 190,
	.y_max			= 3830,
	.vref_delay_usecs	= 100,
	.x_plate_ohms		= 576,
	.y_plate_ohms		= 366,
	.pressure_max		= 15000,
	.debounce_max		= 1,
	.debounce_rep		= 0,
	.debounce_tol		= (~0),
	.get_pendown_state	= ads7846_pendown_state,
};

static struct spi_board_info bcm2708_spi_devices[] = {
	{
		.modalias = "spi-ssd1289",
		.max_speed_hz = 16000000,
		.bus_num = 0,
		.chip_select = 0,
		.mode = SPI_MODE_0,
	},
	{	
		.modalias	= "ads7846",
		.chip_select	= 1,
		.bus_num		= 0,
		.max_speed_hz	= 5000 * 26,
		.platform_data	= &ads_info,
		.irq		= -1, 
	}
};
#endif

.....

void __init bcm2708_init(void)
{
.....
#ifdef CONFIG_SPI
	bcm2708_spi_devices[1].irq=gpio_to_irq(PEN_DOWN_STATE_PIN);
	spi_register_board_info(bcm2708_spi_devices, ARRAY_SIZE(bcm2708_spi_devices));
#endif
.....
}

2. You have to recompile kernel with touchscreen support by enabling this module:
"Device drivers->Input device support->Touchscreens->ADS7846/TSC2046/AD7873 and AD(S)7843 based touchscreens"
3. You have to load ads7846 modue

In my case the cursor was moving in the opposite directions when I touch the screen in the lower right corner it goes to the upper left corner. So I modify "linux/drivers/input/touchscreen/ads7846.c"

Code: Select all

....
static void ads7846_report_state(struct ads7846 *ts)
{
...
if (Rt) {
		struct input_dev *input = ts->input;
                struct ads7846_packet *packet = ts->packet;

		if (ts->swap_xy)
			swap(x, y);

		x=pdata->x_max+320-x;
		y=pdata->y_max+280-y;

		if (!ts->pendown) {
			input_report_key(input, BTN_TOUCH, 1);
			ts->pendown = true;
			dev_vdbg(&ts->spi->dev, "DOWN\n");
		}

		input_report_abs(input, ABS_X, x);
		input_report_abs(input, ABS_Y, y);
		input_report_abs(input, ABS_PRESSURE, ts->pressure_max - Rt);

		input_sync(input);
		dev_vdbg(&ts->spi->dev, "%4d/%4d/%4d\n", x, y, Rt);
	}
...
}
...

now it works fine.

[Norefall]

Thank you valdodov

[mwilliams03]

Hi valdodov , great info thanks.

Based on your post, I have purchased this;
http://www.amazon.com/gp/product/B008FW ... UTF8&psc=1
SainSmart 3.2" TFT LCD Display+Touch Panel+PCB, which uses;
SSD1289:240 RGB x 320 TFT Driver
ADS7843:4-WIRE TOUCH

Do you think I would have any issue getting this working?
I have previously been able to get 1.8" TFTs working via SPI.

[valdodov]

Hi mwilliams03,

i think you'll be OK if you have correct pinout of the LCD.

[notro]

I need help understanding how the interface circuit works.

This is my current understanding:

• The driver clocks out 4 bytes (32 bits) per pixel/command/data.
  The 4040 divides the clock by 32 meaning after reset Q5 is LOW for 32 bits and then HIGH for 32 bits, and so on.
  The 4094 STR input transfers the data from the shift register to the output when HIGH.
  Since the 4094 clock is positive edge triggered, it will have all data when the 4040, which clock is negative edge triggered, pulls Q5=STR HIGH

Assumption: We call ssd1289_spi_write_datablock() with len>1 meaning CS will stay low for the entire transmission. Meaning no reset of the 4040.
Here is one thing I don't understand:
At the end of the first 4 bytes Q5 goes high and transfers the data to the output. But what about the next 4 bytes? Q5 goes LOW and the data is lost?

[valdodov]

Hi guys,

some people ask me for video of this LCD. You can find it on the following link:

https://www.youtube.com/watch?v=ES-Fg1-PuEw

Cheers

[valdodov]

I need help understanding how the interface circuit works.

This is my current understanding:

• The driver clocks out 4 bytes (32 bits) per pixel/command/data.
  The 4040 divides the clock by 32 meaning after reset Q5 is LOW for 32 bits and then HIGH for 32 bits, and so on.
  The 4094 STR input transfers the data from the shift register to the output when HIGH.
  Since the 4094 clock is positive edge triggered, it will have all data when the 4040, which clock is negative edge triggered, pulls Q5=STR HIGH

Assumption: We call ssd1289_spi_write_datablock() with len>1 meaning CS will stay low for the entire transmission. Meaning no reset of the 4040.
Here is one thing I don't understand:
At the end of the first 4 bytes Q5 goes high and transfers the data to the output. But what about the next 4 bytes? Q5 goes LOW and the data is lost?

This "The 4040 divides the clock by 32 meaning after reset Q5 is LOW for 32 bits and then HIGH for 32 bits, and so on" was my wrong assumption too.

if you take a look at the picture

you will notice that 4040 goes low after 16 clocks not after 32. This is the tricky part of the circuit.

[notro]

Thanks for clearing that up valdodov.

Now I will try to understand the whole process:

74HC4040 12-Stage Ripple Carry Binary Counters
This is a frequency divider and using Q5 divides the clock by 2^4=16.
Max frequency: VCC = 3.3 V Min~=18MHz Typ~=54 MHz (linear approximation between 2.0V and 4.5V)
Clock is negative edge triggered

74HC4094 8-stage shift-and-store bus register
Max frequency: VCC = 3.3 V Min~=18MHz Typ~=57 MHz (linear approximation)
Clock is positive edge triggered
Strobe is active HIGH (the contents of the registers is available at the output).
STR is connected to 4040:Q5

SSD1289
WR - write strobe signal. From datasheet: WR input serves as data write latch signal (clock) when low provided that CS is low.
Write cycle (case 1): Set D/C, CS=LOW, WR=LOW, set data, WR=HIGH, CS=HIGH
Write cycle (case 2): Set D/C, WR=LOW, CS=LOW, set data, CS=HIGH, WR=HIGH
CS is connected to STR (shows on Spritemods schematic, not on valdodov's)

Operation
Before the clocks starts: U1:Q5 is LOW => STR is inactive LOW => LCD_CS is active LOW. WR=active LOW.

First 16 bits is clocked into the shift registers on the rising edge. Shift-register outputs is not changing.
When the clock falls on the 16th bit, Q5 goes HIGH => STR goes active HIGH => LCD_CS goes inactive HIGH. Changes to WR will not matter now.

Then 16 more bits is shifted in, this time the output changes at the same time.
When the clock falls on the 32nd bit, Q5 goes LOW => STR goes inactive LOW => LCD_CS goes active LOW.

During all this WR is active LOW. So LCD_CS has to be the one latching/strobing the data => Write cycle case 2.

So when is the data latched in?
According to Table 13-2 – Parallel 8080 Timing Characteristics in the datasheet, it happens when CS goes HIGH (edge triggered).
This happens on the falling clock edge after the first 16 bits. This means it latches in the previous transfer, because the current one hasn't finished yet.

Timing
STR goes active outputting new data, while at the same time LCD_CS goes inactive latching in the old data.
For this to work the old data must be latched in before the new data is STRobed out.
According to the 4094 datasheet, STR has a propagation delay of ~34ns.
Since the data is latched into the LCD controller during the rise of Q5, the new data is available 34ns after the old data was latched in.


Conclusion
The last data sent to the shift-register is not written to the LCD controller.
With these chips, I guess 32MHz SPI speed should be possible at room temperature? 16MHz should be rock stable. (see this for available speeds on the PI: http://www.raspberrypi.org/phpBB3/viewt ... 94#p224394)
The HCT chip variants can not be used because they have Vcc min=4.5V


Comments anyone?

[valdodov]

Hi notro,

You are correct for this:

CS is connected to STR (shows on Spritemods schematic, not on valdodov's)

I forgot to draw this. Now the circuit is corrected.

With these chips, I guess 32MHz SPI speed should be possible at room temperature? 16MHz should be rock stable.

It works fine at 16MHz. At 32MHz it almost works but there are a lot dots with false color on the screen.

You are not quite correct for this:

The last data sent to the shift-register is not written to the LCD controller.

The last data sent to the shift register will be latched in the LCD when you try to write next byte. It happens all the time because there are changes to the screen (cursor blinks, clock changes, mouse movement, etc.)