320x240 LCD with integrated SSD1289 controller

[RaspNoob]

There are 2 chip select (chip enable) pins exposed on the main GPIO pin header so using two devices at the same time should not be too hard (they should share clock, miso and mosi, each has their own "chip enable").
see http://www.brianhensley.net/2012/07/get ... ry-pi.html for some details.

I am not sure if that will work or not...because from what i see... It looks like one of the select lines is being used for the display and the other for the touchscreen.... So, i am not sure if its possible to use a mux to create like a subselect and control them with one of the other GPIOs.. Also.. is the data always being pushed into the MOSI so how does me adding a new circuit to do other stuff with the SPI going to work?
So i have 2 dilemmas....
1. How to "freeze" the LCD and use the SPI port for other parallel circuitry..
2. Easy way to switch between the LCD and normal HDMI since I dont see anything on HDMI anymore...

Any ideas on where to find any references would be great

[khmauli]

Hello guys,

first i want to thank all of you for the great work.

I'm quite new in all this stuff, so first thing i did was to compile the raspberry kernel without any of the tft patches.
I just wanted to see if it works, after that was done i tried to apply the patches, got some errors and then tried to modify the files manually, ... so far so good, when i now try to compile the kernel i get this errors:

Code: Select all

drivers/video/ssd1289.c:597:22: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »ssd1289_probe«
drivers/video/ssd1289.c:762:22: Fehler: expected »=«, »,«, »;«, »asm« or »__attribute__« before »ssd1289_remove«

lines 597 and 762 are:

Code: Select all

static int __devinit ssd1289_probe(struct spi_device *dev)
static int __devexit ssd1289_remove(struct spi_device *dev)	

after searching the net, i find out that attributes __devinit and __devexit have been removed from version 3.8.x on

so i tried to compile with __init instead of __devinit and __exit instead of __devexit

now i can compile the kernel, if i load this to the pi ssd1289 module is loaded, lsmod shows:

Code: Select all

Module                  Size  Used by
ssd1289                20500  0 
fb_sys_fops             1403  1 ssd1289
sysimgblt               2527  1 ssd1289
sysfillrect             3733  1 ssd1289
syscopyarea             2927  1 ssd1289
i2c_dev                 5779  0 
snd_bcm2835            17038  0 
snd_pcm                85078  1 snd_bcm2835
snd_seq                54629  0 
snd_timer              21923  2 snd_pcm,snd_seq
snd_seq_device          6465  1 snd_seq
snd                    60651  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
snd_page_alloc          5344  1 snd_pcm
evdev                   9896  1 
joydev                  9842  0 
leds_gpio               2166  0 
hid_logitech_dj        11012  0 
led_class               3682  1 leds_gpio
i2c_bcm2708             3992  0 
spi_bcm2708             4725  0 

but there is still no fb1 device in /dev.

anybody an idea how to fix this?

thanks, Karsten

[davidwk]

I have my lcd wired up following the diagrams and I have the kernel module installed and loaded. All of that went fine but it never actually creates the /dev/fb1 device. I've been looking through the code in the kernel patch and I can't find where the device would actually get created. It seems to me that udev would need to get involved at some point but I'm having problems finding when that is. Does anyone have a suggestion of where to start looking?

I'm running kernel v3.6.11 and using Valdodov's patch.

Thanks for the help

[notro]

The device is added in arch/arm/mach-bcm2708/bcm2708.c
Something like this:

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,
   }
};

[khmauli]

Thank you for the answers,

i used the wiring shown at http://marks-space.com/2013/05/23/raspb ... h-control/, and i also included the spi device in bmc2708.c

after endless cross compiling i decided to start from beginning, using kernel 3.6.11 and finally i got it, i had a registered ssd1289 device and also i had a /dev/fb1 device, but only a white screen.

I checked the wiring several times, and that seemed to be ok, so because i don't have an oscilloscope i started with lower frequency on the ssd1289 driver, i wanted to check the output of the 4094 IC's with a LED.
The first values i put in seemed to be to low, spi device could not be registered, at something around 10 kHz i saw a few moving pixels on the screen, and finally at 2 MHz i got a stable picture, but frame rate is below 1 fps.
If i try to set the frequency above 2 MHz i only get my white screen. I don't have much experience with all this stuff, but if a got a stable picture on my LCD that means that both, the driver and also the wiring, are ok, right?

Looks like that the 50mA on the 3,3 volt line of the RaspberryPi is not enough to drive the circuit above 2MHz, if i think about this now, i read something about somewhere in this thread. I try to implement a 5V to 3,3V converter in the circuit, hope that will work.

Many thanks to:

XaLKiDEoS, notro, valdodov, mwilliams03 and all the others for your work, i never would have success without you.

@notro: really great work on your framebuffer device library

Karsten

[notro]

On my Sainsmart 3.2" display, I connect Vcc to 5V.

[bigdane]

Hi Notro,

We are trying to run the Sainsmart 3.2" with a raspberry pi.
Installation according to https://github.com/notro/fbtft/wiki is already done.
We have wired the LCD without the SPI interface with following wiring:

reset 29
dc 2
wr 31
db00 11
db01 9
db02 10
db03 22
db04 27
db05 17
db06 4
db07 3
db08 7
db09 8
db10 25
db11 24
db12 23
db13 18
db14 14
db15 15

We tried to load the driver with following command:
sudo modprobe fbtft_device name=sainsmart32fb rotate=0 debug=3 gpios=reset:29,dc:2,wr:31,db00:11,db01:9,db02:10,db03:22,db04:27,db05:17,db06:4,db07:3,db08:7,db09:8,db10:25,db11:24,db12:23,db13:18,db14:14,db15:15

Unfortunately the display still shows only the white backlight.

dmesg shows following errors:

[ 62.544104] fb_ssd1289 fb_ssd1289.0: fbtft_request_gpios: gpio_request_one('db05'=17) failed with -16
[ 62.558246] fb_ssd1289: probe of fb_ssd1289.0 failed with error -16

Could you please help us solving this issue?
Do you need further information?

Thank you very much

Best regards from Germany

bigdane

[notro]

fb_ssd1289 fb_ssd1289.0: fbtft_request_gpios: gpio_request_one('db05'=17) failed with -16

-16 is -EBUSY. That means the GPIO has already been requested by some driver/program, and is not available.

[bigdane]

Hi Notro,

Thank you for the information.
As we couldn't find the program / driver which requests the GPIO 17 we prepared a second SD Card with the Wheezy Image with FBTFT support.
Unfortunately the name=sainsmart32 was not supported, we updated the FBTFT version and the display is working fine!!

Could you please describe whats the difference between sainsmart32, sainsmart32_fast, sainsmart32_latched and sainsmart32_spi?

Thanks & Regards

Daniel

[notro]

we prepared a second SD Card with the Wheezy Image with FBTFT support.
Unfortunately the name=sainsmart32 was not supported

I didn't think people would use the image when I started to release with rpi-update, but I was wrong
The image is old, and the device and driver naming has changed since.
The reason I have it available, is because it can be used to do fbtft development.
Maybe I have to update it...

Could you please describe whats the difference between sainsmart32, sainsmart32_fast, sainsmart32_latched and sainsmart32_spi?

sainsmart32 - uses a 16-bit gpio bus. It uses kernel function gpio_set_value() to switch the gpio's.

sainsmart32_fast - uses a 16-bit gpio bus. It writes directly to the BCM2835 registers to switch the gpio's. On my setup this doesn't work (lots of pixel errors)

sainsmart32_latched - uses a latched 8-bit gpio bus. Has never been tested as far as I know. It was discussed in this forum thread: http://www.raspberrypi.org/phpBB3/viewt ... 14#p365414

sainsmart32_spi - uses the SPI bus to drive the display through a SPI interface circuit: https://github.com/notro/fbtft/wiki/SPI ... ce-circuit

[bigdane]

I didn't think people would use the image when I started to release with rpi-update, but I was wrong
The image is old, and the device and driver naming has changed since.
The reason I have it available, is because it can be used to do fbtft development.
Maybe I have to update it...

Yes, I also saw that the FBTFT version is not up to date after trying to load the driver

sainsmart32 - uses a 16-bit gpio bus. It uses kernel function gpio_set_value() to switch the gpio's.

sainsmart32_fast - uses a 16-bit gpio bus. It writes directly to the BCM2835 registers to switch the gpio's. On my setup this doesn't work (lots of pixel errors)

sainsmart32_latched - uses a latched 8-bit gpio bus. Has never been tested as far as I know. It was discussed in this forum thread: viewtopic.php?p=365414#p365414

sainsmart32_spi - uses the SPI bus to drive the display through a SPI interface circuit: https://github.com/notro/fbtft/wiki/SPI ... ce-circuit

If I understand you right, this means for our setup we have to use sainsmart32?
At this stage we don't need more that two free GPIOs after wiring the LCD.
Are there any other arguments for the SPI interface circuit?

Thanks

bigdane

[notro]

If I understand you right, this means for our setup we have to use sainsmart32?

Yes

At this stage we don't need more that two free GPIOs after wiring the LCD.
Are there any other arguments for the SPI interface circuit?

The SPI solution is much slower, but you get the benefit of the touch panel. With 16-bit gpio bus there's not enough pins to use the SPI touch controller on the display.

[peterhum]

Hi notro

Sorry to revert back to so old a post, but I'm attempting to follow your steps from your original post back on 15 Feb 2013 to recompile the kernel (because i want to out of interest. This is my first time mucking around in kernel land).

So far I've:
1. downloaded linux source per your wiki article
2. applied the original patch from spritemods using "patch -p4 < ~/502-ssd1289-support-linux-3.3.8.diff"
3. manually edited the drivers/video/Makefile cause he patch didn't work, adding the SSD1289 line. I suspect this was caused by linnux version differences.
4. ran make menuconfig.
My problem is here because I don't see the 'Solomon Systech SSD1289 controller support' option under the 'Support for frame buffer devices' menu.
5. I then ran: 'zcat /proc/config.gz > .config' per your later post, to no effect.
6. I also replaced the contents of ssd1289.c and added the 'static struct spi_board_info bcm2708_spi_devices' code to bcm2708.c.

The drivers/video/Kconfig file seems to have all the SSD1289 associated lines from the patch.

Could you give me any pointers as to the source of the problem?

Thanks very much - really appreciate your work with this.

[notro]

Step 4 and 5 have to switch places. Step 5 overwrites 4, and in step 4 you won't see the driver, because you get default values and FB is not set, which FB_SSD1289 depends upon.

If you don't have a custom .config, but uses a default Raspberry Pi kernel, you can do this instead

Code: Select all

# default Raspberry Pi kernel config
make bcmrpi_defconfig

# then enable the driver
make menuconfig

[Stonemull]

Hi smart people.

I ordered a SSD1289 2.4 inch display for a PIC project last week and in googling found this thread .. which reminded me I still did not have a raspi, so ordered one of them too.
So far .. I have a raspberry pi and no display yet, but after browsing every one of these displays on aliexpress I see some (most?) are supplied in 8 bit mode and some perhaps 16 bit mode. Most of the suppliers do not mention which mode it is in at all!
I am also a bit confused in that several here mention 8 bit mode using d0-d7 yet a few suppliers mention that d8-d15 are used in 8 bit mode and d0-d7 should be tied low.
As someone previously noted, the mode is set by resistors on the lcd flex cable and the lcd must be lifted to see.
For those having issues getting it working, this may be the reason.

What I was wondering is whether the entire interface circuit could be avoided if the SSD1289 was used in its pure SPI mode by setting up the flex resistors appropriately, it will be slower than the parallel latch method but much the same speed as using shift registers. Not done a schematic up yet but the pi should then have enough GPIO to use the SPI touch controller, the LCD controller and even the extra SD card slot if desired since you just need the SPI and the chip selects from the GPIO.

at least one supplier mentions that the resistors can be fitted as requested, so perhaps we could get a supply chain of lcd's preset for SPI mode and start using these LCD's with nothing more than some wire links and a few resistors for the backlight, unless I am somehow missing something important

Anyway, I have just registered here, my specialtys are hardware generally and I hope to make myself useful in that aspect, I have a great deal of PIC experience but man, my linux skills are not up to scratch.

[notro]

I am also a bit confused in that several here mention 8 bit mode using d0-d7 yet a few suppliers mention that d8-d15 are used in 8 bit mode and d0-d7 should be tied low.

That depends on how the breakout board has wired the controller pins to the header. There seem to be a 40-pin header standard among these modules, but I have seen thoses that don't follow this also.

From the SSD1289 datasheet: http://www.kosmodrom.com.ua/el/STM32-TFT/SSD1289.pdf

15.2 Mapping for Writing an Instruction
This shows which LCD controller pins is used in the different 8080 modes.

Table 6-2 - Interface Logic Pins
D0-D17 Unused pins must be float or connect to VSS (GND).

15.1.2 8080-series System Bus Interface
Table 15-3 – Interface Mode Selection
Controller pin PS0 toggles between 8/16 bit databus. It can't be done in software.

What I was wondering is whether the entire interface circuit could be avoided if the SSD1289 was used in its pure SPI mode by setting up the flex resistors appropriately

Have you checked that the SPI signals is available on the flex cable?

Not done a schematic up yet but the pi should then have enough GPIO to use the SPI touch controller, the LCD controller and even the extra SD card slot if desired since you just need the SPI and the chip selects from the GPIO.

There are only 2 SPI Chip Selects (CE0,CE1) brought out on the P1 header.

[peterhum]

Step 4 and 5 have to switch places. Step 5 overwrites 4, and in step 4 you won't see the driver, because you get default values and FB is not set, which FB_SSD1289 depends upon.

Thanks very much notro.

[alberthrocks]

notro, is the information on your wiki up to date regarding the FPS for Sainsmart 3.2"/SSD1289? Were there any advancements in trying to raise the frequency (and therefore, the FPS)?

[Stonemull]

Good point nostro,
it appears the SPI pins are not available, having used other controllers I assumed they would be repurposed D0-D2 or similar.
That would be the part I missed

also .. it looks like its the older ILI9325 controller as the COG that used the higher d8-d15 in 8 bit mode. The majority of the 2.4 inch versions (often called a TK1105) indicate that 8 bit mode is the default still and the original hardware here seems to assume 16 bit mode will be used. worth checking on specific LCD's if they do not work as expected.

damn, I thought the SPI will be available on the flex pcb even if not broken out to the 40 pin header. Looking at the data for one of the LCD's used though it seems that is not the case.
I looked at a pdf for the 240374PQ which is a ILI9325 fitted device. The 37 pin flex has no SPI lines unfortunately.

I can see on the breakout connector silkscreen a CS line for the LCD controller, the touch controller, the SD card and the not fitted flash.

named CS, T_CS ,SD_CS, F_CS respectively..

[notro]

notro, is the information on your wiki up to date regarding the FPS for Sainsmart 3.2"/SSD1289? Were there any advancements in trying to raise the frequency (and therefore, the FPS)?

Assuming you're talking about using the SPI interface circuit, I haven't tested it after FBTFT got SPI DMA support. I'll put it on my list to test that (if my breadboarded circuit still works). Will report back here.

[alberthrocks]

notro, is the information on your wiki up to date regarding the FPS for Sainsmart 3.2"/SSD1289? Were there any advancements in trying to raise the frequency (and therefore, the FPS)?

Assuming you're talking about using the SPI interface circuit, I haven't tested it after FBTFT got SPI DMA support. I'll put it on my list to test that (if my breadboarded circuit still works). Will report back here.

Should I assume that the other reported FPS values remain the same?

[notro]

Should I assume that the other reported FPS values remain the same?

The Par. 16-bit value of 11 fps is the same. I tried driving the gpio registers directly (not using the kernel functions), but that gave lots of transmission errors. Maybe it would work if I had the display on a shield right on top of the Pi, keeping wires short... but it wouldn't help much I think in terms of fps.

This 3.5" SPI display without touch panel is supported by fbtft: https://github.com/notro/fbtft/wiki/LCD ... #tinylcd35 12fps using dma.
Forum thread: http://www.raspberrypi.org/phpBB3/viewt ... 52#p442252

[alberthrocks]

Should I assume that the other reported FPS values remain the same?

The Par. 16-bit value of 11 fps is the same. I tried driving the gpio registers directly (not using the kernel functions), but that gave lots of transmission errors. Maybe it would work if I had the display on a shield right on top of the Pi, keeping wires short... but it wouldn't help much I think in terms of fps.

This 3.5" SPI display without touch panel is supported by fbtft: https://github.com/notro/fbtft/wiki/LCD ... #tinylcd35 12fps using dma.
Forum thread: http://www.raspberrypi.org/phpBB3/viewt ... 52#p442252

Sorry if I sound a little silly - but two questions:

• Is it still possible to use an external resistive touchscreen if I used this display? (With some adhesive to the LCD, of course.)
• How is the display when watching films, playing animation, etc. at 10-15 FPS? Is smooth GUI animation (like on iOS) possible on such a display?

[notro]

Is it still possible to use an external resistive touchscreen if I used this display? (With some adhesive to the LCD, of course.)

It should be possible, but I have never done that.
Note: The prebuilt FBTFT kernel has only support for the ads7846 touch driver.

How is the display when watching films, playing animation, etc. at 10-15 FPS? Is smooth GUI animation (like on iOS) possible on such a display?

I haven't studied this, so I don't know. I just make the display work with FBTFT and then move on
Try asking in this thread: http://www.raspberrypi.org/phpBB3/viewt ... p?p=442252

[alberthrocks]

It should be possible, but I have never done that.
Note: The prebuilt FBTFT kernel has only support for the ads7846 touch driver.

I guess I'll be sticking to this one then, in lieu of some wiring (and driver) experimentation!

I haven't studied this, so I don't know. I just make the display work with FBTFT and then move on
Try asking in this thread: http://www.raspberrypi.org/phpBB3/viewt ... p?p=442252

I meant for displays in general that you've worked with... though it's understandable if you're just a "get-it-implemented" person and don't really look at the screen too much!