Gert's VGA add-on for the B+

[jdb]

I'm very curious as to what the secondary memory interface is good for. I noticed it has a wide data bus, but only a few address lines, so it it for some kind of paged block mode flash device, like a K9K2G16Q0M, or for some kind of FIFO RAM?
Or something else altogether.
Is it possible to add a fast swap mechanism (virtual memory) using it?
Or, I'm speculating even more, for a SATA interface....

I believe it was originally used to talk to NAND chips directly (which multiplex command/address/data on the bus, and use the "address" lines as chipselects), but is sufficiently configurable that it can be used as a generic address/data bus.

There's several peripherals on the general distribution market that could theoretically talk to this interface.

[dom]

I'm very curious as to what the secondary memory interface is good for. I noticed it has a wide data bus, but only a few address lines, so it it for some kind of paged block mode flash device, like a K9K2G16Q0M, or for some kind of FIFO RAM?
Or something else altogether.
Is it possible to add a fast swap mechanism (virtual memory) using it?
Or, I'm speculating even more, for a SATA interface....

It's been used for small displays and NAND flash in the past. It supports DMA so has decent performance, although it doesn't clock very fast (maybe 20MHz?).
Yes, it's more suitable for paged/block devices that random access.
SATA sounds possible - it may not be a lot faster than USB, but would allow disk and network to operate in parallel.

[Gert van Loo]

The speed of the interface can not be easily given.
We found the GPIO's can cope with 120 MHz input on a single input.
The limit for a single output was about ~80-90MHz. (Where the digital signal looked more like a sine-wave)
If a lot of pins bounce up and down that deteriorates. That is more or less what I said in the GPIO spec.
(http://www.scribd.com/doc/101830961/GPIO-Pads-Control2)
And all that depends on what you connect to it and how you connect to it.

Bottom line: there is no hard figure this is really a case of trial-and-error.

[ceteras]

Has anybody succeed connecting an LCD panel to the DPI port?
I've tried two variants and both failed. One 480x272 4.3" parallel interfaced display and one 1024x768 lvds with a transmitter adapter.
I've got a lot more troubleshooting to do, so I won't post questions about it yet.

I'd like to know somebody else did it, though.

[RaTTuS]

Has anybody succeed connecting an LCD panel to the DPI port?
I've tried two variants and both failed. One 480x272 4.3" parallel interfaced display and one 1024x768 lvds with a transmitter adapter.
I've got a lot more troubleshooting to do, so I won't post questions about it yet.

I'd like to know somebody else did it, though.

only the RPi foundation - as they have access to all the internal bits to make it work -

[ceteras]

only the RPi foundation - as they have access to all the internal bits to make it work -

You mean they did a prototype LCD on the DSI port.
I'm talking about connecting an LCD panel to the DPI port which is used for the VGA interface, did they do that too?

[RaTTuS]

my bad ... did not look properly at the thread
what DPI port
this is about Gerts VGA adapter which uses all the GPIO on the B+

if you have an LCD panel which only has a VGA interface [??] then this should work - if you have and LCP panel which has a DVI interface then a HDMI to DVI adapter will work fine

[ceteras]

Gert's VGA adapter is an application for an interface called DPI which became available since B+ .

This is what I've called a DPI port. It's a parallel display interface. Very similar to a standard interface used in LCD panels.
I mean LCD panels, not LCD displays/monitors.

The trick is that for LCD panels you need two more signals which are available on GPIO0 and GPIO1, which are reserved for HAT (seriously, who needs automatic configurations on a raspberry pi, the computer built for learning and used by geeks?).
Those two signals can be accessed when GPIO0/1 are set in mode ALT2, so it's not a very straight-forward feature.
Perhaps many B+ owners don't even realise they could try this.
But still I hope I'm not the only one interested in this.

[Gert van Loo]

Interesting back ground information on this:
The software which is running the VGA port IS an LCD driver.
All I did was convert the LCD digital signals to analogue level.
(Oh... and NOT use pixel clock or enable)

So: yes, you can use it for LCD and yes, it has been done before.
(The driver was originally written for the LCD from a big phone manufacturer)

[Burngate]

(The driver was originally written for the LCD from a big phone manufacturer)

Does any manufacturer make big phones any more?

[jdb]

(The driver was originally written for the LCD from a big phone manufacturer)

Does any manufacturer make big phones any more?

Apple, apparently

http://mentalfloss.com/sites/default/le ... 65x565.jpg

[robotron]

With driver for this is there any control over the frequency of the outputed signal?
If so could it be slowed down to produce a lower resolution display thats at
the 15Khz with a 50 to 60hz refresh rate to produce a signal compatible
with an old CRT screen via the RGBS input on its SCART connector

[mikronauts]

Update:

I won't be making these boards, as there is a better way for UK/EU Pi'ers ... see

https://www.kickstarter.com/projects/pi ... spberry-pi

if you want a kit... much cheaper for UK/EU ! (due to insane Canada Post rates)

(Just found it in https://www.kickstarter.com/projects/pi ... spberry-pi)

[Joe Schmoe]

I won't be making these boards, as there is a better way for UK/EU Pi'ers ... see

Too bad. What about us US/Canada people, who will now have to deal with UK overseas shipping headaches?

[RaTTuS]

I won't be making these boards, as there is a better way for UK/EU Pi'ers ... see

Too bad. What about us US/Canada people, who will now have to deal with UK overseas shipping headaches?

kick start a Canadian one ?

[ceteras]

With driver for this is there any control over the frequency of the outputed signal?
If so could it be slowed down to produce a lower resolution display thats at
the 15Khz with a 50 to 60hz refresh rate to produce a signal compatible
with an old CRT screen via the RGBS input on its SCART connector

Try the custom modes described by dom here: http://www.raspberrypi.org/forums/viewt ... 26#p613926 .
I think you will need to get it to work in interlaced mode for the SCART connector CRT and play with different resolutions until you get it right (640x480, 800x600 or around that, but not higher) .

Edit: some CRT's can be damaged by improper sync frequencies, so be careful! An oscilloscope or at least a frequency counter would be required to check the signals first.

[HeBus]

Hi,
This is my 1st post in this forum, so first : a BIG THANKS to the whole Raspberry Pi team and foundation for their GREAT work. And a special mention to Gert and Dom who unveiled details about this DPI interface. This is exactly what I needed to play with something I have been eager to try for some time : driving LCD panels directly in LVDS.
I just bought a brand new B+ board (my original 2012 rev1 was too old for this...) and gave it a shot with a scope.
What I managed to do so far :

• enabled Pixel Clock and Data Enable signals on GPIO_0 and GPIO_1 through a custom dt-blob.bin . (this forbids the use of ID pins for HAT detection, but doesn't matter, kernel just sees this as "no connected HAT"). These are the lines I added to dt-blob-dpi.dts :

  Code: Select all

  pin@p0  { function = "dpi";  termination = "no_pulling";    }; // Pixel Clock
  pin@p1  { function = "dpi";  termination = "no_pulling";    }; // Data Enable
  

• tried "dpi_output_format=7" and got 24bits color depth signals
• Tried several display modes and inspect signals on an oscilloscope. Even managed to use custom timings through the use of "hdmi_timings=" option in config.txt (not dpi_timing as I tried 1st)

Everything works just fine, I am almost to the point where I could start routing a small board to serialize those data in LVDS for a panel.
The problem is : the DATA ENABLE signal I observe have perfect timings but negative polarity. Every datasheet found on the net show DATA ENABLE high for data transfer, but the one out of RPi is low when transferring.
Anyone can confirm this? Somebody knows how to change output polarity (maybe through device tree dts/dtb)?

[mikronauts]

I could make them - the problem is that I need to make 100 to make the price affordable to y'all.

So far, I can use up to 7 myself, and only 5 were spoken for, leaving 88 in limbo.

I just don't want to be stuck with 88 extra PCB's.

I won't be making these boards, as there is a better way for UK/EU Pi'ers ... see

Too bad. What about us US/Canada people, who will now have to deal with UK overseas shipping headaches?

[mikronauts]

I suppose I could, however it would take more of my time, and I can easily have 100 boards made without kickstarter - I just don't want to sit on 88 board forever.

Frankly, I was surprised at how few people expressed interest.

I won't be making these boards, as there is a better way for UK/EU Pi'ers ... see

Too bad. What about us US/Canada people, who will now have to deal with UK overseas shipping headaches?

kick start a Canadian one ?

[ceteras]

Hi,

Code: Select all

pin@p0  { function = "dpi";  termination = "no_pulling";    }; // Pixel Clock
pin@p1  { function = "dpi";  termination = "no_pulling";    }; // Data Enable

Anyone can confirm this? Somebody knows how to change output polarity (maybe through device tree dts/dtb)?

Have you tried something like this?

Code: Select all

pin@p1  { function = "dpi";  termination = "no_pulling";  polarity="active_high"  }; // Data Enable

[Joe Schmoe]

Frankly, I was surprised at how few people expressed interest.

Me, too. I guess it's the "Well, I can just do it tomorrow" factor.

One needs to set (artificial) deadlines for these things to work.

Anyway, I'd be willing to get one, but I suppose the ship has sailed.

Maybe it is better to let the kickstarted folks do it instead.

[HeBus]

Now I did : no change
I had already seen those lines in dt-blob-dpi.dts, but I suspect "polarity=active_high" is only a valid option for input signals.

[ceteras]

Try active_low, for the sake of trying.
I'm very interested in this too (but I only have a frequency counter, no scope, to test it).
If it's still reversed, you could fix it with a fast inverter logic circuit (74F04 or something).


Edit:

Code: Select all

pin@p16 { function = "output"; termination = "pull_up"; polarity = "active_low"; }; // activity LED

Outputs have polarity too.

[mikronauts]

Thank you for trying it!!!!

This is excellent news!

Inverting DE is not a big deal, and it may be possible to invert it through some I/O setting.

Hi,
This is my 1st post in this forum, so first : a BIG THANKS to the whole Raspberry Pi team and foundation for their GREAT work. And a special mention to Gert and Dom who unveiled details about this DPI interface. This is exactly what I needed to play with something I have been eager to try for some time : driving LCD panels directly in LVDS.
I just bought a brand new B+ board (my original 2012 rev1 was too old for this...) and gave it a shot with a scope.
What I managed to do so far :

• enabled Pixel Clock and Data Enable signals on GPIO_0 and GPIO_1 through a custom dt-blob.bin . (this forbids the use of ID pins for HAT detection, but doesn't matter, kernel just sees this as "no connected HAT"). These are the lines I added to dt-blob-dpi.dts :

  Code: Select all

  pin@p0  { function = "dpi";  termination = "no_pulling";    }; // Pixel Clock
  pin@p1  { function = "dpi";  termination = "no_pulling";    }; // Data Enable
  

• tried "dpi_output_format=7" and got 24bits color depth signals
• Tried several display modes and inspect signals on an oscilloscope. Even managed to use custom timings through the use of "hdmi_timings=" option in config.txt (not dpi_timing as I tried 1st)

Everything works just fine, I am almost to the point where I could start routing a small board to serialize those data in LVDS for a panel.
The problem is : the DATA ENABLE signal I observe have perfect timings but negative polarity. Every datasheet found on the net show DATA ENABLE high for data transfer, but the one out of RPi is low when transferring.
Anyone can confirm this? Somebody knows how to change output polarity (maybe through device tree dts/dtb)?

[HeBus]

Still no luck. I had also tried active_low, now added pull_up... No change. "polarity" may only be active for GPIO and do nothing once pin have been dedicated to dpi. I will try to find the kernel code that reads the device tree file and program pins, to see if I find a hint...