Gert's VGA add-on for the B+

[mikronauts]

I've been using 240R and 270R resistors on the Parallax Propeller VGA output for quite a few years, with quite a few CRT and LCD monitors, without issues. As the Propeller is also a 3.3V chip, I suspect those values would work for the RPi B+ ... I will be testing this hypothesis

[J Sanderson]

"but for 1bit version, you draw 9.45mA from the RGB pins."
My maths (probably wrong!) gives 3.3/275=0.012 Amps per colour

Surely the number of bits used doesn't affect the current draw?
A white screen would be 275 Ohm cumulatively for one bit through to 8 bit?

I do see though that you have to be careful as DPI will be drawing over half the total permitted 50mA and with more GPIO pins free to use you could very easily draw too much if you don't buffer things.

If 80 Ohms has to be used for VSYNC & HSYNC my maths seem to give 41.25mA drain on both! I suspect that because these are only short blips of power drain that is why it can be got away with?

[ceteras]

The load on sync signals is not the same as on the RGB pins, so that math does not apply.

For the 1bit part, you have 275 ohm in series with the 75ohm load inside the monitor, you get 350ohm load for each RGB pin.

"A white screen would be 275 Ohm cumulatively for one bit through to 8 bit?"
For each less significant bit, the current drawn would be half of its next significant bit.
If you make the sum of all the bits except the most significant one, you get the most significant one minus 1. That is almost equal.
So if you use more than one bits for this, it will always be just under double the load you have for a single bit.
It is quite obvious as the more less significant bits you add, the less current each one will add to the white screen load.

[dom]

I suppose that every option may be useful then AFAIC, any way of specifying all these is good for me : structure mapped into u32 bits, or some "dpi_settings=<rgb_order> <output_format> ..." line similar to hdmi_timings.
Thanks again for taking care about this.

An initial solution is in the latest firmware update. config.txt option dpi_output_format can control all the dpi peripheral fields.
Where fields are zero, it should behave as before. The single bit fields all act as an "invert default behaviour".

Code: Select all

    output_format          = (dpi_output_format >>  0) & 0xf;
    rgb_order              = (dpi_output_format >>  4) & 0xf;

    output_enable_mode     = (dpi_output_format >>  8) & 0x1;
    invert_pixel_clock     = (dpi_output_format >>  9) & 0x1;

    hsync_disable          = (dpi_output_format >> 12) & 0x1;
    vsync_disable          = (dpi_output_format >> 13) & 0x1;
    output_enable_disable  = (dpi_output_format >> 14) & 0x1;

    hsync_polarity         = (dpi_output_format >> 16) & 0x1;
    vsync_polarity         = (dpi_output_format >> 17) & 0x1;
    output_enable_polarity = (dpi_output_format >> 18) & 0x1;

    hsync_phase            = (dpi_output_format >> 20) & 0x1;
    vsync_phase            = (dpi_output_format >> 21) & 0x1;
    output_enable_phase    = (dpi_output_format >> 22) & 0x1;

Code: Select all

output_format:
   1: DPI_OUTPUT_FORMAT_9BIT_666
   2: DPI_OUTPUT_FORMAT_16BIT_565_CFG1
   3: DPI_OUTPUT_FORMAT_16BIT_565_CFG2
   4: DPI_OUTPUT_FORMAT_16BIT_565_CFG3
   5: DPI_OUTPUT_FORMAT_18BIT_666_CFG1
   6: DPI_OUTPUT_FORMAT_18BIT_666_CFG2
   7: DPI_OUTPUT_FORMAT_24BIT_888

rgb_order:
   1: DPI_RGB_ORDER_RGB
   2: DPI_RGB_ORDER_BGR
   3: DPI_RGB_ORDER_GRB
   4: DPI_RGB_ORDER_BRG

output_enable_mode                 : 0: DPI_OUTPUT_ENABLE_MODE_DATA_VALID  1: DPI_OUTPUT_ENABLE_MODE_COMBINED_SYNCS
invert_pixel_clock                 : 0: RGB Data changes on rising edge and is stable at falling edge  1: RGB Data changes on falling edge and is stable at rising edge.
hsync/vsync/output_enable_polarity : 0: default for HDMI mode  1: inverted
hsync/vsync/oe phases              : 0: DPI_PHASE_POSEDGE  1: DPI_PHASE_NEGEDGE

[AirRietveld]

I was wondering if it would be possible to have the VGA output and the composite signal as separate outputs. It states everywhere that you can build a dual monitor setup with VGA and HDMI, but how about the composite output? Is this a copy of the HDMI signal?

[dom]

I was wondering if it would be possible to have the VGA output and the composite signal as separate outputs. It states everywhere that you can build a dual monitor setup with VGA and HDMI, but how about the composite output? Is this a copy of the HDMI signal?

Composite and VGA (through DPI) can be driven concurrently.
The second display is not a copy of the first. You need to run apps specifiying the display number (e.g. omxplayer has a display number as a command line option).
Mirroring the two displays automatically is not supported (and generally doesn't make sense due the differing resolution/aspect ratio/framerate).

[AirRietveld]

I don't want it to be a copy, so that would be good.

[Fat D]

Is there a particular reason for the hsync/vsync/oe disable bits and DPI mode 4 (which is a strict subset of mode 6)? Does it reduce load on the VC to disable unused outputs? Will the chip drive the pins with the DPI signal without respect to the pin mux settings? Or is it just to reduce power consumption / RF emissions / OCD for unused signals?

[r1ch999999]

I said I was in for one with the guy making them, but I never heard more.

Another question, the Banana Pro has the same gpio pinout as the B+, any idea if this vga add-on would work?

[mikronauts]

Hi,

I shelved it, as previously posted, as the Pi Hut got it into production and with only about 8 responses, I did not want to order the 200pcb's it would have taken to make the PCB inexpensive. If I ordered only 20pcb's, it would be cheaper for buyers to order from Pi Hut as the PCB's would have cost me approx. $5 each - before shipping, taxes, duty etc.

The Banana Pro has a compatible connector, but it has a totally different video subsystem, so it is not possible to use this circuit on it.

I said I was in for one with the guy making them, but I never heard more.

Another question, the Banana Pro has the same gpio pinout as the B+, any idea if this vga add-on would work?

[r1ch999999]

Hi,

I shelved it, as previously posted, as the Pi Hut got it into production and with only about 8 responses, I did not want to order the 200pcb's it would have taken to make the PCB inexpensive. If I ordered only 20pcb's, it would be cheaper for buyers to order from Pi Hut as the PCB's would have cost me approx. $5 each - before shipping, taxes, duty etc.

The Banana Pro has a compatible connector, but it has a totally different video subsystem, so it is not possible to use this circuit on it.

I missed the shelving bit then, thanks for letting me know. Also, thanks for the info about the banana pro.

[mikronauts]

You are most welcome, and no worries!

We are all here to have fun with these great little SBC's.

(I am constantly thinking of new uses for the $20 A+ ... that is an amazing price point)

Hi,

I shelved it, as previously posted, as the Pi Hut got it into production and with only about 8 responses, I did not want to order the 200pcb's it would have taken to make the PCB inexpensive. If I ordered only 20pcb's, it would be cheaper for buyers to order from Pi Hut as the PCB's would have cost me approx. $5 each - before shipping, taxes, duty etc.

The Banana Pro has a compatible connector, but it has a totally different video subsystem, so it is not possible to use this circuit on it.

I missed the shelving bit then, thanks for letting me know. Also, thanks for the info about the banana pro.

[Fat D]

Another question, the Banana Pro has the same gpio pinout as the B+, any idea if this vga add-on would work?

I had a quick look, it looks like the display FPC connector on the Banana Pro supports DPI (unlike the RPi's, which does DSI), so you might be able to hack up an adapter using a 40-pin FPC cable and breakout. Be sure to look up the drive capabilities of the BPi SoC first to avoid nasty surprises.

[r1ch999999]

I wonder if one of the suptronic boards that has an hdmi to vga adapter would still let this board work with the gpio. I'm not sure exactly what gpio lines are used by those boards and how they'd interfere with each other. That would be neat though.

[mikronauts]

It's possible, assuming there is a driver.

Another question, the Banana Pro has the same gpio pinout as the B+, any idea if this vga add-on would work?

I had a quick look, it looks like the display FPC connector on the Banana Pro supports DPI (unlike the RPi's, which does DSI), so you might be able to hack up an adapter using a 40-pin FPC cable and breakout. Be sure to look up the drive capabilities of the BPi SoC first to avoid nasty surprises.

[PR77]

Hi There,

I have a couple of small Sharp LCD panels (400x240) with a parallel interface I'm planning to connect to the Pi. I have all the data for the LCD available and from my initial investigations the interface seems to be suitable with the DPI. Has any been able to get their own parallel interface RAW LCD panels working with the DPI? Additional I have been able to find any hint o how to set an arbitrary resolution (400x240), is this possible?

Thanks!

[mikronauts]

That would depend on the Pi Foundation releasing either information or a utility to allow setting the dot clock, vertical & horizontal front and back porches, vertical and horizontal sync values, active pixels per line and active lines per frame. Something like the X.org mode lines.

Hi There,

I have a couple of small Sharp LCD panels (400x240) with a parallel interface I'm planning to connect to the Pi. I have all the data for the LCD available and from my initial investigations the interface seems to be suitable with the DPI. Has any been able to get their own parallel interface RAW LCD panels working with the DPI? Additional I have been able to find any hint o how to set an arbitrary resolution (400x240), is this possible?

Thanks!

[r1ch999999]

Didn't I read a teaser about a possible LCD board being released this year?

I just discovered that the Banana Pro I ordered already has a 7 inch LCD available, I'm interested to see how much it'll be in a few months.

[dom]

That would depend on the Pi Foundation releasing either information or a utility to allow setting the dot clock, vertical & horizontal front and back porches, vertical and horizontal sync values, active pixels per line and active lines per frame. Something like the X.org mode lines.

Have you read my posts in this thread? I believe all the settings are configurable though config.txt

[mikronauts]

dom,

My apologies - I forgot about that!

Now that you have mentioned it, I do recall your posts a while ago.

My excuse is that I am old and grey.

I will investigate config.txt thoroughly... I have quite a few raw panels in my lab.

Update - Links to relevant posts in this thread:

dom (config.txt to set display mode)
http://lb.raspberrypi.org/forums/viewto ... 61#p628061

dom (how to set mode/resolution)
http://lb.raspberrypi.org/forums/viewto ... 26#p613926

dom (pixel modes, etc)
http://lb.raspberrypi.org/forums/viewto ... 38#p617738

dom (dpi display structure)
http://lb.raspberrypi.org/forums/viewto ... 19#p617719

HeBus (how to enable pixel clock)
http://lb.raspberrypi.org/forums/viewto ... 62#p617662

That would depend on the Pi Foundation releasing either information or a utility to allow setting the dot clock, vertical & horizontal front and back porches, vertical and horizontal sync values, active pixels per line and active lines per frame. Something like the X.org mode lines.

Have you read my posts in this thread? I believe all the settings are configurable though config.txt

[PR77]

Hi,

Thanks for your feedback. I did in fact check these posts however I don't quiet understand how with these settings set the DPI to display a resolution of 400x240. Am I missing something?

Thanks!

dom,

My apologies - I forgot about that!

Now that you have mentioned it, I do recall your posts a while ago.

My excuse is that I am old and grey.

I will investigate config.txt thoroughly... I have quite a few raw panels in my lab.

Update - Links to relevant posts in this thread:

dom (config.txt to set display mode)
http://lb.raspberrypi.org/forums/viewto ... 61#p628061

dom (how to set mode/resolution)
http://lb.raspberrypi.org/forums/viewto ... 26#p613926

dom (pixel modes, etc)
http://lb.raspberrypi.org/forums/viewto ... 38#p617738

dom (dpi display structure)
http://lb.raspberrypi.org/forums/viewto ... 19#p617719

HeBus (how to enable pixel clock)
http://lb.raspberrypi.org/forums/viewto ... 62#p617662

That would depend on the Pi Foundation releasing either information or a utility to allow setting the dot clock, vertical & horizontal front and back porches, vertical and horizontal sync values, active pixels per line and active lines per frame. Something like the X.org mode lines.

Have you read my posts in this thread? I believe all the settings are configurable though config.txt

[rpdom]

From a quick look at those posts I'd say something like

Code: Select all

dpi_cvt 400 240 50 6
dpi_group=2
dpi_mode=87

would be a start. That's assuming the refresh rate for your screen is 50Hz and 15:9 ratio.

You'll have to check the figures and put in suitable values.

[PR77]

Brilliant! I will check this once I get a chance! Perhaps I will try and post a picture!

From a quick look at those posts I'd say something like

Code: Select all

dpi_cvt 400 240 50 6
dpi_group=2
dpi_mode=87

would be a start. That's assuming the refresh rate for your screen is 50Hz and 15:9 ratio.

You'll have to check the figures and put in suitable values.

[PR77]

Time for an update. I can't get the DPI working. On hand I only have a 2GB Micro SD Card so I'm using RISC OS, but reading older posts this shouldn't make a difference.

Measuring the outputs signals with a CRO I can see the RGB signals jumping around (good sign) however the V+H Sync show after a reset 1-2 second burst of activity and then steady state. Additionally the P_CLK and DE signals don't look "digital" at all (I've compiled the DTS as described enabling P0 and P1). With the P_CLK and DE signals it almost looks like there is bus contention on the IO as the signals are less than 0-1V peak. I would expect c.a. 3.3V peak.

EDIT: Given the P_CLK and DE are with "no_termination" possibly I either need to externally terminate (with 100K pull up / down) or re-compile the DTS to set a termination type. This might explain the straight signals here. Question: If a GPIO is set to "no_termination" is the output structure a "simple" open collector / open drain?

Code: Select all

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

Eliminating a potential fault with the LCD or the interface PCB I made I removed these and probed the bare Raspi B+ and observed the same behaviour. I (re)downloaded the latest firmware from github to ensure this was OK; no change.

Interestingly I am only seeing the above mentioned activity with the following config.txt;

Code: Select all

enable_dpi_lcd=1
display_default_lcd=1
dpi_output_format=5

#dpi_cvt 400 240 50 6
#dpi_group=2
#dpi_mode=87
#dpi_mode=82

rgb_order=1

However when I using the following;

Code: Select all

enable_dpi_lcd=1
display_default_lcd=1
dpi_output_format=5

dpi_cvt 400 240 50 6
dpi_group=2
dpi_mode=87
#dpi_mode=82

rgb_order=1

There is no activity on the DPI port at all. I hope I'm missing something stupid! I'm open to debugging suggestions.

Thanks!

Brilliant! I will check this once I get a chance! Perhaps I will try and post a picture!

From a quick look at those posts I'd say something like

Code: Select all

dpi_cvt 400 240 50 6
dpi_group=2
dpi_mode=87

would be a start. That's assuming the refresh rate for your screen is 50Hz and 15:9 ratio.

You'll have to check the figures and put in suitable values.

[Fat D]

EDIT: Given the P_CLK and DE are with "no_termination" possibly I either need to externally terminate (with 100K pull up / down) or re-compile the DTS to set a termination type. This might explain the straight signals here. Question: If a GPIO is set to "no_termination" is the output structure a "simple" open collector / open drain?

Code: Select all

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

Eliminating a potential fault with the LCD or the interface PCB I made I removed these and probed the bare Raspi B+ and observed the same behaviour. I (re)downloaded the latest firmware from github to ensure this was OK; no change.

Interestingly I am only seeing the above mentioned activity with the following config.txt;

Code: Select all

enable_dpi_lcd=1
display_default_lcd=1
dpi_output_format=5

#dpi_cvt 400 240 50 6
#dpi_group=2
#dpi_mode=87
#dpi_mode=82

rgb_order=1

DPI works for me by duplicating the existing DPI rows from the VGA device tree for the extra pins needed. Be sure that you compile the new blob correctly as per http://www.raspberrypi.org/documentatio ... uration.md - I had issues by mixing up -o and -O. Your issue of getting an analog signal that does not exceed 1V sounds like all you get is capacitively-coupled interference from the other lines - which makes sense if both ends of the line are unterminated inputs.

However when I using the following;

Code: Select all

enable_dpi_lcd=1
display_default_lcd=1
dpi_output_format=5

dpi_cvt 400 240 50 6
dpi_group=2
dpi_mode=87
#dpi_mode=82

rgb_order=1

There is no activity on the DPI port at all. I hope I'm missing something stupid! I'm open to debugging suggestions.

Thanks!

Brilliant! I will check this once I get a chance! Perhaps I will try and post a picture!

From a quick look at those posts I'd say something like

Code: Select all

dpi_cvt 400 240 50 6
dpi_group=2
dpi_mode=87

would be a start. That's assuming the refresh rate for your screen is 50Hz and 15:9 ratio.

You'll have to check the figures and put in suitable values.

I just figured this out the hard way. CVT works for DPI, but you still need to set up the custom mode with hdmi_cvt, not dpi_cvt. I forsee problems if/when multi-screen support comes out, but for now, this is how it goes.