Gert's VGA add-on for the B+

[mikronauts]

In case you have not seen it, there is a new B+ add-on design by Gert, the designer of the Gertboard, GertDuino and many other excellent boards. The blog post about it is at:

http://www.raspberrypi.org/gert-vga-adapter/

The bad news is that it chews up the I2C, serial and SPI pins.

The good news is it should drive pretty much any VGA monitor.

I am hoping the HSync/VSync can be moved from the I2C pins.

In an extremely generous move, Gert released the files as freeware. See the github for details:

https://github.com/fenlogic/vga666

The timing is fortuitous, as I am in the process of ordering more RoboPi and other boards, so I plan to make about 10 VGA boards for my uses (I have 7 B+'s so far). I could easily have many more made, however I won't know the costs until I know how many I'll need to make.

I am based in Canada, and can ship fairly cheaply to the US and Canada in case anyone is interested, however shipping is too high to UK/EU for small orders. Fortunately it sounds like Gert may have a UK supplier lined up.

I normally have my boards made as ENIG, FR4, 1oz copper, blue solder mask (RoHS & Lead Free), e-tested.

I'd get the boards about 2-3 weeks after ordering them.

Basically, I am posting because I'd like to get some idea of how many boards I should have manufactured, as my costs for the PCB's varies significantly depending on the quantity I order.

[jamesh]

AIUI, the adapter needs all those GPIO's and the DPI pins cannot be moved.

[mikronauts]

Thanks James.

It is still great for many uses. I was very happy to see the announcement, I have ~15 nice new 7" VGA LCD screens without DVI or hdmi sitting in their original packaging that this will be perfect for making small HMI's monitoring test gear in my lab. I'll just plug a USB-serial converter in to feed data to the B+

Is there an accessible dot clock and display enable on the GPIO header, to allow driving LCD panels?

p.s.

I'm about half done wiring up a prototype for playing with!

AIUI, the adapter needs all those GPIO's and the DPI pins cannot be moved.

[hippy]

AIUI, the adapter needs all those GPIO's and the DPI pins cannot be moved.

I was wondering about using 'unused pins', especially if going from 3 x 6-R DACs to just 3 x 1-R DACs catering for 8 colour mode. I guess it all depends on whether the SoC switches the GPIO en masse for DPI usage or not.

It's a very welcome addition and well done to Gert and anyone else who had a hand in it.

I was also wondering if it were possible to use the same / similar to build a composite video output using the same tricks. That could be monochrome only but still useful as it could be used alongside HDMI.

Does the 'driver' run in the GPU ? And/or will that be open-sourced for people who want to experiment / attempt such things ?

[mikronauts]

Hi Hippy!

git clone the repo, and look at the PDF docs... my read indicates that you can run it with as few as five GPIO's in an eight color mode, 8 GPIO's for a 64 color mode (sounds familiar?) etc all the way up to the 20 pin / 18 bit color mode on Gert's board.

The repo only had binary blobs, the GPL seems to refer to the Cadence schematics/layout/docs.

The biggest limitation seems to be the required specific pins, especially as the I2C interface is used for HSync/VSync.

AIUI, the adapter needs all those GPIO's and the DPI pins cannot be moved.

I was wondering about using 'unused pins', especially if going from 3 x 6-R DACs to just 3 x 1-R DACs catering for 8 colour mode. I guess it all depends on whether the SoC switches the GPIO en masse for DPI usage or not.

It's a very welcome addition and well done to Gert and anyone else who had a hand in it.

I was also wondering if it were possible to use the same / similar to build a composite video output using the same tricks. That could be monochrome only but still useful as it could be used alongside HDMI.

Does the 'driver' run in the GPU ? And/or will that be open-sourced for people who want to experiment / attempt such things ?

[hippy]

git clone the repo, and look at the PDF docs... my read indicates that you can run it with as few as five GPIO's in an eight color mode, 8 GPIO's for a 64 color mode (sounds familiar?) etc all the way up to the 20 pin / 18 bit color mode on Gert's board.

Thanks; I'd already done that ( well, downloaded the .zip on my desktop PC ). It wasn't clear if using the 5 GPIO pin setup all 2-22 GPIO pins would still be allocated for DPI use or would become free for other use. That is, 5 GPIO only saved resistors, not gave unused GPIO back.

[mikronauts]

bottom of page 6 of the documentation PDF says:

Can I reduce the number of GPIO pins it uses?
Yes. You can drop the LS colours bits of each channel which will free up more GPIO pins but the
picture quality will get worse as you lose more colours. If you use less resistors you also have to adapt
the values. (See section: Calculations).

I am hoping that is correct as I could see lower color depth modes being very useful due to more I/O being left.

git clone the repo, and look at the PDF docs... my read indicates that you can run it with as few as five GPIO's in an eight color mode, 8 GPIO's for a 64 color mode (sounds familiar?) etc all the way up to the 20 pin / 18 bit color mode on Gert's board.

Thanks; I'd already done that ( well, downloaded the .zip on my desktop PC ). It wasn't clear if using the 5 GPIO pin setup all 2-22 GPIO pins would still be allocated for DPI use or would become free for other use. That is, 5 GPIO only saved resistors, not gave unused GPIO back.

[geemac2000]

Hey Mikronauts I was hoping somebody would get some pcb's going . I would like 2 if you do decide to go ahead with the order. I'm also based in Canada.

[mikronauts]

Cool! Where are you? I am in Langley, BC.

At least shipping will be cheap, I can use regular letter mail within Canada for pcb's.

I'll need to order at least 100 to get a decent price on the boards... so 100-(7+2)... 91 to go!

As long as I get confirmation for at least 50 I'll order the 100 boards, I figure that I can flog them over time.

I should have my hand-wired prototype of Gert's circuit running tomorrow, I've soldered the connector and added all the resistors. I need to go back and verify everything, then I'll solder all those resistors (I used 26 instead of 20, to get closer to ideal values), then add one of my VGA mini-modules (minus resistors) that I originally made for the Propeller. I'll post a pic when it is done, and probably blog about it on my site.

Can't wait to test it with my 7" VGA OEM modules, I'll spruce up my workstations with some nice home made instrumentation.

Hey Mikronauts I was hoping somebody would get some pcb's going . I would like 2 if you do decide to go ahead with the order. I'm also based in Canada.

[geemac2000]

I'm in Cornwall Ontario

[ceteras]

[...]

Is there an accessible dot clock and display enable on the GPIO header, to allow driving LCD panels?

[...]

I'm also interested in this. The two pins are crucial for connecting lcd screens.
If they're not available, the signals can be extracted from syncs using some PLL magic, but that's tricky.

[jdb]

GPIO0 and 1 are PCLK and DE (which conflicts with the HAT ID pins, if you're thinking of turning an adapter board into a HAT).

[ceteras]

I'd rather have the functionality than the HAT. I hope it's not going to be very difficult to enable those pins.

[hippy]

Can I reduce the number of GPIO pins it uses?
Yes. You can drop the LS colours bits of each channel which will free up more GPIO pins but the picture quality will get worse as you lose more colours. If you use less resistors you also have to adapt the values. (See section: Calculations).

I am hoping that is correct as I could see lower color depth modes being very useful due to more I/O being left.

Same here; let's hope "free up more GPIO" means what we believe it does.

It also seems it may be possible to use the same scheme to deliver VGA for the A and B models using just the 26-way headers if prepared to be limited to 1024 colour VGA. Having unrouted GPIO pins is no longer a problem if not used.

It might require some interface layer to change colour wanted to what is needed in the frame buffer and then streamed out via DPI but that should overcome having most significant bit colour signals on unrouted GPIO pins and therefore not available. I couldn't find any documentation on using DPI so don't know if it is actually possible or not. I would have expected it was.

[PiGraham]

It also seems it may be possible to use the same scheme to deliver VGA for the A and B models using just the 26-way headers if prepared to be limited to 1024 colour VGA. Having unrouted GPIO pins is no longer a problem if not used.

I think I just read somewhere that the most significant bits map to GPIO not accessible on A/B, so you can't run this on those models.

[jojopi]

On Model A/B Rev1, GPIO2/3 (V/H sync) are only available on the camera connector, and on Rev2 GPIO21 (red7) is. So even 8 colour mode is difficult to wire. GPIO20 (red6) is completely missing.

With specially constructed framebuffer data though (or palletted 8bit?), I see nothing to stop you using less significant bits instead. That would allow 64 colours (2+2+2) on a Rev2 without any wiring issues, or possibly 4096 colours (4+4+4) with board modification to steal GPIO16 from the ACT LED.

[Gert van Loo]

Thanks James.

It is still great for many uses. I was very happy to see the announcement, I have ~15 nice new 7" VGA LCD screens without DVI or hdmi sitting in their original packaging that this will be perfect for making small HMI's monitoring test gear in my lab. I'll just plug a USB-serial converter in to feed data to the B+

Is there an accessible dot clock and display enable on the GPIO header, to allow driving LCD panels?

p.s.

I'm about half done wiring up a prototype for playing with!

AIUI, the adapter needs all those GPIO's and the DPI pins cannot be moved.

Is there an accessible dot clock and display enable on the GPIO header, to allow driving LCD panels?

Yes! (ut you loose two more GPIO pins) GPIO0 is the pixel clock, GPIO1 is the enable.
But there are officially reserved for HAT EEPROMS.

[mikronauts]

Thanks jdb!

Can I request driver support for the PCLK and DE? It would allow using bare LCD panels in addition to VGA mode, and I have several applications in mind where I willingly use up all those GPIO and HAT compatibility for a nice cheap 7" bare panel!

It should not affect sales of the nice DSI panels the Foundation is about to launch because for the vast majority of applications I (and others) would prefer to not use all those GPIO's.

GPIO0 and 1 are PCLK and DE (which conflicts with the HAT ID pins, if you're thinking of turning an adapter board into a HAT).

[mikronauts]

Thank you again!

This is great, it means as long as I don't need "HAT" status and don't mind losing the I/O, I should be able to drive raw LCD panels. (with a bit of additional binary driver blob support, or eventual open-source driver (I can dream))

The B+ has just become a viable option for many more applications for me, ditto for the CM.

Regarding the reserved I2C port...

if I understand correctly, it became reserved to avoid potential issues during the boot process, so with some care, using it for PCLK & DE after boot should not be an issue. The "garbage" that the LCD would see on those lines during boot could be avoided by gating the signals so they only get to the LCD after boot.

Is there an accessible dot clock and display enable on the GPIO header, to allow driving LCD panels?

Yes! (ut you loose two more GPIO pins) GPIO0 is the pixel clock, GPIO1 is the enable.
But there are officially reserved for HAT EEPROMS.

[ceteras]

Thanks jdb!

Can I request driver support for the PCLK and DE?
[...]

+1

[jdb]

As a manual workaround, use a GPIO-poking interface (wiringpi or similar) to directly set GPIO0 and GPIO1 to ALT2 to gain access to PCLK and DE.

[mikronauts]

Thank you!

As a manual workaround, use a GPIO-poking interface (wiringpi or similar) to directly set GPIO0 and GPIO1 to ALT2 to gain access to PCLK and DE.

[mikronauts]

I did some rough back-of-the-envelope calculations.

I am not intending to make a profit on Gert's gerbers, but I do need to make sure I don't lose money.

Assuming I order at least 100pcb's made from Gert's gerbers, I'd have to sell the bare PCB's for somewhere between $2-$3 each (so I don't actually lose money, and shipping for up to 10 boards would be approx. $6 to Canada and USA (NOT insured, your risk, not trackable, includes my packaging cost) using letter mail within Canada, and "Light Packet USA" to the states. Tracked/insured is much more expensive.

For those of you outside of US/Canada, shipping would be a lot more... sorry, CanadaPost has gone nuts on pricing this year, especially on anything that is insured and/or trackable, which has really hurt my low quantity sales.

They are even slapping a $10 "handling" fee on incoming shipments for collecting the 12% of GST+PST (VAT equivalent), I ended up paying $38USPS for shipping, plus $36 (GST+PST+"handling" when I received it on my recent Compute Dev Kit purchase (from the US)! (UPS/FedEx express charge $14 handling) After a certain volume, it is possible to get the taxes back, but not the handling fee.

To get a reasonable per pcb shipping cost outside of US/Canada, a group buy would be needed. You can look up shipping costs to your location at http://canadapost.ca, use postal code "V3A 6J2" for the "from" clocation. I use 6.5"x4.5"x(1"...3") boxes. I suspect EU/UK orders will only make sense at 25+ pcb's, I will add $2 to cover shipping materials etc. If a lot of people commit to 25+ boards, I will make a larger than 100pcb order.

Web shops are welcome to order Gert's gerber boards on this basis from me as well.

If people want, I can add $1 to the price of each board, to be paid to Gert or the Raspberry Pi Foundation.

[Gert van Loo]

....

Can I request driver support for the PCLK and DE? ....

There is no need for specific driver support. As all the pins are driven by hardware the signals ARE already present.
They just don't come out until you set the GPIO pins to DPI mode.

Now if you read the manual very carefully you should be able to find out how to get these signals out.
Hint: look at the installation section and at all the files present on github.

[mikronauts]

Thank you!

This finally gives me a sufficient reason to deep-dive into the Broadcomm docs

....

Can I request driver support for the PCLK and DE? ....

There is no need for specific driver support. As all the pins are driven by hardware the signals ARE already present.
They just don't come out until you set the GPIO pins to DPI mode.

Now if you read the manual very carefully you should be able to find out how to get these signals out.
Hint: look at the installation section and at all the files present on github.