guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Sat Jun 22, 2013 3:03 pm

I should also confess that there is this additional file:

Code: Select all

NET "miso" LOC = "P34";
NET "mosi" LOC = "P29";
NET "sclk" LOC = "P28";
NET "sel"  LOC = "P33";
NET "outputs<0>" LOC = "P1";
NET "outputs<1>" LOC = "P2";
NET "outputs<2>" LOC = "P3";
NET "outputs<3>" LOC = "P4";
NET "outputs<4>" LOC = "P8";
NET "outputs<5>" LOC = "P9";
NET "outputs<6>" LOC = "P35";
NET "outputs<7>" LOC = "P36";
NET "outputs<8>" LOC = "P37";
NET "outputs<9>" LOC = "P38";
NET "outputs<10>" LOC = "P43";
NET "outputs<11>" LOC = "P44";
NET "outputs<12>" LOC = "P11";
NET "outputs<13>" LOC = "P12";
NET "outputs<14>" LOC = "P13";
NET "outputs<15>" LOC = "P14";
NET "cs" LOC = "P18";
NET "wr" LOC = "P19";
NET "pi_reset" LOC = "P5";
NET "pi_cd" LOC = "P26";
NET "reset" LOC = "P20";
NET "cd" LOC = "P24";
NET "ena" LOC = "P22";
This one maps the logical signals whose behaviour is specified in the previous post onto the I/O of the device itself (i.e., the 'P' numbers are the physical pins on the chip).
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Sat Jun 22, 2013 3:30 pm

I have just ordered one, I need to look more into this :-)
guzunty wrote: My reading of the SSD1289 interface specification led me to believe that data is latched either on the rising edge of 'wr' (if 'cs' is low) or the rising edge of 'cs' (if 'wr' is low). I could be wrong, but there seemed to me to be a potential race condition if 'cs' and 'wr' are allowed to rise together as they are in some sprite-mod derived circuits. Accordingly, the CPLD design raises the 'wr' signal on the falling edge of the SPI clock, which is one half SPI clock cycle before 'cs' rises with SPI_CS0.
The SSD1289 is a special controller in that it can use CS for latching. I haven't seen this in other controllers. Spritemod does it like that. I use WR to be compatible with other controllers.
Yes, the datasheet keeps CS and WR apart, but there is no timing specification for the delay.
guzunty wrote: How do I go about being sure I have an exactly vanilla wheezy-raspbian release? Do you just mean an up to date installation according to apt-get?
I'm referring to the Raspbian “wheezy” image on the downloads page. The FBTFT image is based on this.

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Sat Jun 22, 2013 3:52 pm

guzunty wrote: Specifically, there are 12 pins left over on the Guzunty which I would like to use as inputs. Since the LCD interface is write only, I would like to transfer the value of these across the SPI0.0 bus as data is clocked out to the display.
It can be done, but a special framebuffer driver has to be made. One that pushed the values being read somewhere. The problem with this approach, is that no pins will be read if there is no display updates. Of course additional logic can be added to the driver to handle this. But it's not a good solution, separation of concerns is a good design principle.
guzunty wrote: Notro, you have a great understanding of linux devices and their drivers, how do you think I should best make these pins available to the user?
I would say making a SPI slave inside the CPLD to read the pins is a good approach, if there is room for that.
But then we have the touch panel that uses SPI. Using SPI for the display and the touchpanel occupies the whole SPI bus (CE0 and CE1).
What sampling rate do you need? Could you make a I2C slave for instance (400kHz)?

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Sat Jun 22, 2013 7:13 pm

]It can be done, but a special framebuffer driver has to be made. One that pushed the values being read somewhere. The problem with this approach, is that no pins will be read if there is no display updates. Of course additional logic can be added to the driver to handle this. But it's not a good solution, separation of concerns is a good design principle.
I totally agree with the separation sentiment. However, squeezing it all into the available hardware sometimes requires compromises. I did figure that I'd need to customise the fb driver. I also thought of the update issue and I think it'll be OK like that, see below.
I would say making a SPI slave inside the CPLD to read the pins is a good approach, if there is room for that. But then we have the touch panel that uses SPI. Using SPI for the display and the touchpanel occupies the whole SPI bus (CE0 and CE1).
There is definitely room for that, and there is another possibility. If we're modifying the kernel anyway, it would be possible to build another SPI channel into the kernel, at the cost of one additional GPIO signal and one CPLD pin.
What sampling rate do you need? Could you make a I2C slave for instance (400kHz)?
The application is a micro MAME cabinet, so the poll frequency does not need to be super high, I think the display refresh rate would be plenty. Also because of the application, we can be sure that the display will be updated very frequently, especially during game play.

I do want to implement everything inside the CPLD if possible but I have not yet tried to implement I2C with the CPLD. I anticipate challenges with it because some I2C signals must be bidirectional. This is not impossible with the CPLD, but is uncharted territory for me. Also, I2C will eat a lot more CPLD resources because the protocol is that bit more complex.

Thank you very much for your order. I'll ship a kit out to you on Monday morning.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Sat Jun 22, 2013 9:40 pm

guzunty wrote: I did figure that I'd need to customise the fb driver. I also thought of the update issue and I think it'll be OK like that, see below.
Adding a custom write() function to the driver can give read/write SPI transfers. Then the input bytes received can be pushed to... How can MAME receive these inputs?
guzunty wrote: If we're modifying the kernel anyway, it would be possible to build another SPI channel into the kernel, at the cost of one additional GPIO signal and one CPLD pin.
Yes, I have thought of that. I don't think it will be hard to add more Chip Selects to the SPI Controller driver. I'm not sure if Chip Select can be turned off in the hardware, but if it can't, CS2 can be used (not available on any header) and the driver can do gpio Chip Select.

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Tue Jun 25, 2013 8:16 am

> How can MAME receive these inputs?

I saw work going on to give MAME the ability to read the GPIO directly, I was thinking of contributing to that work.

Notro, when you build your Guzunty, can I suggest you use one of these?

http://www.adafruit.com/product/1112

The reason being is that I have just routed a daughterboard that will connect the LCD though a nice neat 40 way ribbon cable. The daughterboard needs to connect to both the GPIO header and the Guzunty outputs. Just a thought. You can reuse the standard header supplied to build the daughterboard. Daughterboards should be here in about three weeks.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Tue Jun 25, 2013 9:20 am

guzunty wrote: Notro, when you build your Guzunty, can I suggest you use one of these?

http://www.adafruit.com/product/1112

The reason being is that I have just routed a daughterboard that will connect the LCD though a nice neat 40 way ribbon cable. The daughterboard needs to connect to both the GPIO header and the Guzunty outputs. Just a thought. You can reuse the standard header supplied to build the daughterboard. Daughterboards should be here in about three weeks.
I have a couple of those, and since I have a ribbon cable connected to the Pi header, it's a perfect match for me on the Guzunty.

texy
Forum Moderator
Forum Moderator
Posts: 5160
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Tue Jun 25, 2013 9:10 pm

Hi,
so if I am reading this thread correctly, it should be possible to drive one of these (or other parallel driven displays), via SPI from the Pi at higher speeds than 32mhz and let the Guzunty, or at least a XC9572XL programmed accordingly, deal with the serial to parallel conversion, plus any other clock or control signals required?
What is the maximum fps achieved with this arrangement?
I think I need to order a Guzunty and have a play ;)
Texy
Various male/female 40- and 26-way GPIO header for sale here ( IDEAL FOR YOUR PiZero ):
https://www.raspberrypi.org/forums/viewtopic.php?f=93&t=147682#p971555

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 8:49 am

Hi Texy,

>so if I am reading this thread correctly, it should be possible to drive one of these (or other parallel driven displays), via SPI from the Pi at higher speeds than 32mhz.
You are reading this thread correctly. :-) However, we do not know about maximum bus speed yet.

I can say that it definitely does work at 32MHz and definitely does *not* work at 48MHz at this time. I'm awaiting the arrival of a daughter board I designed that may allow faster operation. We'll know in a few weeks when they come back from the fab. I will post my results then and offer the boards if there is a demand. According to the SSD1289 specification it should work at higher speeds. The CPLD can definitely go faster than 32MHz, I have example projects that work up to the maximum speed of the Pi SPI hardware.

> and let the Guzunty, or at least a XC9572XL programmed accordingly, deal with the serial to parallel conversion, plus any other clock or control signals required?
Yes, using notro's most excellent work, the CPLD handles the SPI to parallel conversion plus the chip select and write signals. Two additional GPIO signals are required for the CD/RS and Reset signals. Enable/Read is tied high.

>What is the maximum fps achieved with this arrangement?
I keep meaning to measure this. I recall reading that at 16MHz the frame rate was measured at around 10fps. I'll try to measure it at 32MHz today and post the results here.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

texy
Forum Moderator
Forum Moderator
Posts: 5160
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 9:22 am

Thanks,
is the daughterboard you are waiting for a modified 'guzunty' pcb, or a different design?
You may be aware that I placed an order for a guzunty kit last night. Will I be able to modify this board with the changes (if they prove successful) ?

In the mean time, I need to research what I need to program and use these CPLD's :)
Cheers,
Texy
Various male/female 40- and 26-way GPIO header for sale here ( IDEAL FOR YOUR PiZero ):
https://www.raspberrypi.org/forums/viewtopic.php?f=93&t=147682#p971555

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 10:03 am

is the daughterboard you are waiting for a modified 'guzunty' pcb, or a different design?
It is a daughterboard that goes on top of a standard Guzunty.
You may be aware that I placed an order for a guzunty kit last night. Will I be able to modify this board with the changes (if they prove successful) ?
Yes, I saw that. Thank you for your order :-) You probably won't need to modify your Guzunty, the daughter card will plug on top and have a 40 way header. You can build this with a male header to use with a ribbon cable or a female to plug the LCD in directly.
In the mean time, I need to research what I need to program and use these CPLD's
To use the ready made cores, you just get the code from the Guzunty GitHub site and build it. You can then use the "gz_load" executable to load the core into the CPLD. To make your own cores, you'll need the Xilinx ISE development tool. Choose the web pack version and its free, but beware, the download is _huge_. Also, you'll need RedHat SUSE Enterprise or Windows to run it.

HTH,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

texy
Forum Moderator
Forum Moderator
Posts: 5160
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 12:51 pm

Ah yes, but I don't even know what a 'core' is yet :lol: and how it fits into the program listings you put up earlier in the thread. I,m guess that a core defines how the logic is configured, ie determines the hardware, then the program listing drives the logic, ie the software. I could be wrong, lol.

Texy
Various male/female 40- and 26-way GPIO header for sale here ( IDEAL FOR YOUR PiZero ):
https://www.raspberrypi.org/forums/viewtopic.php?f=93&t=147682#p971555

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 1:21 pm

Texy, very close but no cigar :D

The listing earlier in the thread is not a conventional program, but VHDL. It defines the required behaviour of the hardware. Instead of getting a breadboard and putting chips and jumpers on it, you write VHDL. The Xilinx ISE tool takes your VHDL and a constraint file that defines which signal is mapped to which pin of the CPLD. It then synthesises an internal representation of the hardware and then fits it into the logic units in the CPLD and produces a 'core', which is a binary file. The core is then loaded into the Guzunty using a utility from the Guzunty website, and the CPLD then acts just as if you had made a breadboard with discrete logic on it. The CPLD stores the core in flash memory, so you only reprogram it when you want to repurpose it. Otherwise, it just comes up when you apply power and behaves the way you programmed it.

The software to drive the programmed logic is written in C, or Python or Scratch or whatever you want to use, just like you would with a breadboard circuit.

As you can probably tell, I think it is amazing! Because you can program it to do anything you can specify in VHDL, this little chip is like hobbyist glue. In other words, it can be used to pull the different parts of any project together, whether it uses an A/D converter, a servo, buttons or an LCD display.

Oh, and did I mention that it can drive most 5 volt logic too?
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 1:51 pm

I am aware I have wandered off topic a bit.

Maybe we should start a separate thread to discuss the merits of the CPLD?
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

texy
Forum Moderator
Forum Moderator
Posts: 5160
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 6:22 pm

Yes,
I think a Guzunty thread in 'other projects' would be appropriate and useful for us newbees.
Texy
Various male/female 40- and 26-way GPIO header for sale here ( IDEAL FOR YOUR PiZero ):
https://www.raspberrypi.org/forums/viewtopic.php?f=93&t=147682#p971555

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 9:51 pm

Back on topic, Texy, in answer to your question:

>What is the maximum fps achieved with this arrangement?

I tested using Notros recommended method using mplayer with a test.mpg file, the current result is between 15 and 17 fps with 32MHz SPI.

best,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

texy
Forum Moderator
Forum Moderator
Posts: 5160
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Wed Jun 26, 2013 10:07 pm

I haven't looked at the spec of the display, but can that be improved upon?
Ie is the display capable, if driven correctly, of a better frame rate......
Texy
Various male/female 40- and 26-way GPIO header for sale here ( IDEAL FOR YOUR PiZero ):
https://www.raspberrypi.org/forums/viewtopic.php?f=93&t=147682#p971555

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Thu Jun 27, 2013 9:22 am

Texy,

Section 14 of the SSD1289 controller specification shows the write waveform.

My reading of it is that there are two key values, tDSW (Data Setup Time) and tDHW (Data hold time). They have minimum values of 5 ns each, which means it should work with SPI speeds up to 100MHz. The CPLD is capable of working at that rate, so in my opinion, yes, a higher frame rate is possible assuming the Pi SOC can can keep up.

We will see what the reality is when the daughter boards arrive.

Notro, what are the consequences of over clocking the SOC for your framebuffer work?
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Thu Jun 27, 2013 1:17 pm

guzunty wrote: Section 14 of the SSD1289 controller specification shows the write waveform.

My reading of it is that there are two key values, tDSW (Data Setup Time) and tDHW (Data hold time). They have minimum values of 5 ns each, which means it should work with SPI speeds up to 100MHz.
Maximum speed is derived from tCYCLE = 100ns = 10MHz. My experience with SPI timing limitations on these controllers show that these values can be pushed considerably.
guzunty wrote: yes, a higher frame rate is possible assuming the Pi SOC can can keep up.
I did a loopback test with a wire between MISO and MOSI, but I can't find the result anywhere. I believe I couldn't get 48MHz to work. But at these speeds, wiring has a lot to say.
Gert van Loo's say on the matter: http://www.raspberrypi.org/phpBB3/viewt ... 86#p230386.
Here's a wiki page I wrote with most of my Raspi SPI knowledge: http://elinux.org/index.php?title=RPi_SPI
guzunty wrote: Notro, what are the consequences of over clocking the SOC for your framebuffer work?
I don't know of any special limitations.

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Thu Jun 27, 2013 1:40 pm

notro wrote:Maximum speed is derived from tCYCLE = 100ns = 10MHz. My experience with SPI timing limitations on these controllers show that these values can be pushed considerably.
Yes, that figure is for the whole write cycle, right? A theoretical SPI bus speed of 100MHz would be divided by 16 which would be well under the tCYCLE time.
notro wrote:I did a loopback test with a wire between MISO and MOSI, but I can't find the result anywhere. I believe I couldn't get 48MHz to work. But at these speeds, wiring has a lot to say.
Gert van Loo's say on the matter: http://www.raspberrypi.org/phpBB3/viewt ... 86#p230386.
Here's a wiki page I wrote with most of my Raspi SPI knowledge: http://elinux.org/index.php?title=RPi_SPI
Interesting. I experimentally cranked up the SPI clock right up on my 7 segment LED driver core and it only went funky at the very top rate. However, my poor scope has no chance of actually looking at 100MHz signals. If they were marginal I would not have known. All I can report is that the display _appeared_ to function perfectly all the way up to (but not including) the very top setting.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Thu Jun 27, 2013 3:05 pm

guzunty wrote:
notro wrote:Maximum speed is derived from tCYCLE = 100ns = 10MHz. My experience with SPI timing limitations on these controllers show that these values can be pushed considerably.
Yes, that figure is for the whole write cycle, right? A theoretical SPI bus speed of 100MHz would be divided by 16 which would be well under the tCYCLE time.
You're right, I was "locked in" on the LCD interface speed :-)
guzunty wrote: Interesting. I experimentally cranked up the SPI clock right up on my 7 segment LED driver core and it only went funky at the very top rate. However, my poor scope has no chance of actually looking at 100MHz signals. If they were marginal I would not have known. All I can report is that the display _appeared_ to function perfectly all the way up to (but not including) the very top setting.
That is indeed good news. Maybe on a good day when the sun is shining, we can drive those 640X480 displays at near movie speed?

Frame: 480x640 pixels x 2 bytes per pixel = 614400 bytes.
SPI: 100MHz 1-bit => 100MHz / 8 = 12.5MHz 8-bit => 12.5x10^6 bytes/s
Transfer speed: (12.5x10^6 bytes/s) / (614400 bytes) = 20 fps

That would be something!

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Thu Jun 27, 2013 3:12 pm

Don't get too excited yet :-)

It occurred to me after leaving the last post that my experiment was done with the standard SPI kernel module code that drops the speed to the next lower power of 2. I recall your patch removes this behaviour. If that is so, it is possible that my experiments all got dropped to 32MHz or less.

I should rebuild that project and repeat the experiment with your patched SPI module. We might still be stuck at 32MHz after all.

I'll report back when I get a chance to try this, but we won't really know what is possible with the SSD1289 until I get the routed daughter cards back from the fab.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Thu Jun 27, 2013 4:09 pm

guzunty wrote:Don't get too excited yet :-)
Well, I was hoping for a miracle :-)

I just tried a loopback test with a latch between MOSI and MISO directly on the header:
* Asking for 42-49MHz gives cdiv=6 resulting in 41.6MHz. This works.
* Asking for 50MHz gives cdiv=5 resulting in 50MHz. This gives transmission errors.

Code: Select all

sudo ./spidev_test -D /dev/spidev0.1 -s 49000000
spi mode: 0
bits per word: 8
max speed: 49000000 Hz (49000 KHz)

FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D

[92495.464417] spidev spi0.1: setup: want 49000000 Hz; bus_hz=250000000 / cdiv=6 == 41666666 Hz; mode 0: cs 0x00000001


sudo ./spidev_test -D /dev/spidev0.1 -s 50000000
spi mode: 0
bits per word: 8
max speed: 50000000 Hz (50000 KHz)

FF FF FF FF FF FF
60 00 00 00 00 CA
FF FF FF FF FF 7F
7F FF FF FF FF FF
FF FF FF FF FF FF
EF D7 DF F7 DD D6
F8 06

[92500.799912] spidev spi0.1: setup: want 50000000 Hz; bus_hz=250000000 / cdiv=5 == 50000000 Hz; mode 0: cs 0x00000001


guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Thu Jun 27, 2013 4:50 pm

Notro, based on your data, I repeated last nights frame rate experiment having requested a 42 MHz SPI.

The frame rate is improved a little to between 16 to 18 fps. It seems objectively smoother too.

Repeating the experiment, setting a 50MHz target SPI speed, the frame rate improves again, but only by a little to between 17 to 18 fps. I did not see any obvious transmission artefacts.

Testing with startx at 50MHz also shows a good desktop with none of the previously seen corruption at 48MHz. I have reconfigured the 'jury-rigged' wiring slightly so that may account for the improved stability. This is moderately encouraging for the likely performance of the daughterboard.

On this basis, I am going to leave mine configured at 50MHz. I will report back if I see problems later.

Of course, YMMV (as indeed may the SOC on your Pi).
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

User avatar
bob_binz
Posts: 441
Joined: Thu Feb 02, 2012 7:58 pm
Location: Stockport, UK

Re: Sainsmart 3.2" (SSD1289) framebuffer driver

Mon Jul 01, 2013 3:19 pm

Does anybody know if the itdb28fb driver should work for any ili9325 based screen? I specifically have this one and have tried connecting using the parallel databus, so far without much luck. There's next to know info on the board, I'm just trying to apply the pinout as described on notro's github. Just thought I'd ask before spending too much time trying to find out what might be wrong.

Return to “Other projects”