Gert's VGA add-on for the B+


241 posts   Page 4 of 10   1, 2, 3, 4, 5, 6, 7 ... 10
by HeBus » Wed Sep 24, 2014 2:07 pm
mikronauts wrote: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.


I do hope that it is possible to invert it by software. It seems crazy to think that broadcom put this DPI feature into the chip and actually picked up the wrong polarity for DE signal. So either I am doing my measurements completely wrong (but other signals DO have good polarity ;-) ), or panels do not really care about DE polarity (as they seem to accept both polarities for HSYNC and VSYNC signals...). Otherwise it must be possible to invert it.
User avatar
Posts: 6
Joined: Wed Sep 24, 2014 11:38 am
by mikronauts » Wed Sep 24, 2014 2:25 pm
I really doubt you are doing your measurements incorrectly.

A 74hc04 (or even an transistor) and we get /DE :)

I really doubt the propogation delay of a single gate on DE will affect LCD timing enough to matter.

HeBus wrote:I do hope that it is possible to invert it by software. It seems crazy to think that broadcom put this DPI feature into the chip and actually picked up the wrong polarity for DE signal. So either I am doing my measurements completely wrong (but other signals DO have good polarity ;-) ), or panels do not really care about DE polarity (as they seem to accept both polarities for HSYNC and VSYNC signals...). Otherwise it must be possible to invert it.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi
User avatar
Posts: 2606
Joined: Sat Jan 05, 2013 7:28 pm
by dom » Wed Sep 24, 2014 2:27 pm
This is the config structure we give to the DPI driver on the GPU. It gives some idea of what is controllable in software:
Code: Select all
//The DPI setup
typedef struct
{
   //the rgb order
   DPI_RGB_ORDER_T rgb_order;

   //the output format
   DPI_OUTPUT_FORMAT_T output_format;

   //output enable mode
   DPI_OUTPUT_ENABLE_MODE_T output_enable_mode;

   //invert pixel clock?
   uint32_t invert_pixel_clock;

   //the h / v sync + output enable 'disable flags'
   uint32_t hsync_disable;
   uint32_t vsync_disable;
   uint32_t output_enable_disable;

   //the h / v sync + output enable polarity
   DPI_POLARITY_T hsync_polarity;
   DPI_POLARITY_T vsync_polarity;
   DPI_POLARITY_T output_enable_polarity;

   //the h / v sync + output enable phase
   DPI_PHASE_T hsync_phase;
   DPI_PHASE_T vsync_phase;
   DPI_PHASE_T output_enable_phase;

} DPI_PERIPH_SETUP_T;

I guess it's the output_enable_polarity (which is set to active low currently).

I need to think of a way of exposing these options.
dt-blob.bin is one possibility
extending hdmi_timings is another
extending dpi_output_format is another

I suspect the whole structure (which is mostly booleans) will fit in the current dpi_output_format word as a 32-bit word with a number of bit fields.
That may be the simplest solution for now. Moving to dt-blob.bin may be a subsequent change when we're a bit clearer on exactly which settings need exposing.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5083
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by BMS Doug » Wed Sep 24, 2014 2:34 pm
mikronauts wrote:Frankly, I was surprised at how few people expressed interest.


I didn't express an interest as it wasn't economically viable (UK resident). Thanks for linking to the UK kickstarter, I've put myself down for one from there.
Doug.
Building Management Systems Engineer.
Posts: 3802
Joined: Thu Mar 27, 2014 2:42 pm
Location: London, UK
by mikronauts » Wed Sep 24, 2014 2:43 pm
Thanks Dom, great info, and a BIG thank you to all of you releasing this info and helping.

Personally, I'd prefer if it was all exposed - who knows what flexibility someone may need?

dom wrote:This is the config structure we give to the DPI driver on the GPU. It gives some idea of what is controllable in software:
Code: Select all
//The DPI setup
typedef struct
{
   //the rgb order
   DPI_RGB_ORDER_T rgb_order;

   //the output format
   DPI_OUTPUT_FORMAT_T output_format;

   //output enable mode
   DPI_OUTPUT_ENABLE_MODE_T output_enable_mode;

   //invert pixel clock?
   uint32_t invert_pixel_clock;

   //the h / v sync + output enable 'disable flags'
   uint32_t hsync_disable;
   uint32_t vsync_disable;
   uint32_t output_enable_disable;

   //the h / v sync + output enable polarity
   DPI_POLARITY_T hsync_polarity;
   DPI_POLARITY_T vsync_polarity;
   DPI_POLARITY_T output_enable_polarity;

   //the h / v sync + output enable phase
   DPI_PHASE_T hsync_phase;
   DPI_PHASE_T vsync_phase;
   DPI_PHASE_T output_enable_phase;

} DPI_PERIPH_SETUP_T;

I guess it's the output_enable_polarity (which is set to active low currently).

I need to think of a way of exposing these options.
dt-blob.bin is one possibility
extending hdmi_timings is another
extending dpi_output_format is another

I suspect the whole structure (which is mostly booleans) will fit in the current dpi_output_format word as a 32-bit word with a number of bit fields.
That may be the simplest solution for now. Moving to dt-blob.bin may be a subsequent change when we're a bit clearer on exactly which settings need exposing.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi
User avatar
Posts: 2606
Joined: Sat Jan 05, 2013 7:28 pm
by mikronauts » Wed Sep 24, 2014 2:47 pm
No worries, and I agree. The only way it was economical to the UK/EU is a bulk order... shipping from Canada to the UK/EU is very high.

Example:

Non-insured, non-trackable "Light Packet Air", must be less than 250gm, less than 20mm thick, is $11+

What's worse, even that rate is not available to some parts of EU.

Shipping from Canada to Asia is even worse.

I am working on getting UK/EU/etc distribution for my products... stay tuned.

BMS Doug wrote:
mikronauts wrote:Frankly, I was surprised at how few people expressed interest.


I didn't express an interest as it wasn't economically viable (UK resident). Thanks for linking to the UK kickstarter, I've put myself down for one from there.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi
User avatar
Posts: 2606
Joined: Sat Jan 05, 2013 7:28 pm
by HeBus » Wed Sep 24, 2014 3:00 pm
Thanks dom for giving a look at this.
dom wrote:I guess it's the output_enable_polarity (which is set to active low currently).

I need to think of a way of exposing these options.
dt-blob.bin is one possibility
extending hdmi_timings is another
extending dpi_output_format is another

I suspect the whole structure (which is mostly booleans) will fit in the current dpi_output_format word as a 32-bit word with a number of bit fields.
That may be the simplest solution for now. Moving to dt-blob.bin may be a subsequent change when we're a bit clearer on exactly which settings need exposing.


Changing dpi_output_format would outdate gert beautiful documentation. I hate writing doc myself, so I wouldn't force somebody else to rewrite its own ;-).
Actually not every bit is usefull. Many of them can be tweaked otherwise :
- HSYNC and VSYNC polarities are already in hdmi_timings
- signal disabling can be done by de-assigning pins in dt-blob

This leaves :
- rgb_order : this is for swapping color bytes? if every panel do not take colors in the same order this may become useful, or to ease PCB routing if some color order is easier than another
- output_format : already in config.txt, if am not mistaken (dpi_output_format?)
- output_enable_mode : what is this?
- invert_pixel_clock : can be done by hard wiring an inversion pin on the serializer I am looking for. But it may be more user-friendly if done in software.
- output_enable_polarity : I definitely want this one ;-)
- hsync/vsync/oe phases : this may be useful, but really hard to tweak without some good diagnostics. Probably not useable by many people. Are these booleans or integers?

For me, a dpi_timings would be perfect, not to mess with the existing hdmi_timings. But you are the programmer in charge ;-)
User avatar
Posts: 6
Joined: Wed Sep 24, 2014 11:38 am
by dom » Wed Sep 24, 2014 3:39 pm
HeBus wrote:This leaves :
- rgb_order : this is for swapping color bytes? if every panel do not take colors in the same order this may become useful, or to ease PCB routing if some color order is easier than another
- output_format : already in config.txt, if am not mistaken (dpi_output_format?)
- output_enable_mode : what is this?
- invert_pixel_clock : can be done by hard wiring an inversion pin on the serializer I am looking for. But it may be more user-friendly if done in software.
- output_enable_polarity : I definitely want this one ;-)
- hsync/vsync/oe phases : this may be useful, but really hard to tweak without some good diagnostics. Probably not useable by many people. Are these booleans or integers?

For me, a dpi_timings would be perfect, not to mess with the existing hdmi_timings. But you are the programmer in charge ;-)


rgb_order can be one of:
DPI_RGB_ORDER_RGB,
DPI_RGB_ORDER_BGR,
DPI_RGB_ORDER_GRB,
DPI_RGB_ORDER_BRG,

output_format is the config.txt setting dpi_output_format
DPI_OUTPUT_FORMAT_9BIT_666,
DPI_OUTPUT_FORMAT_16BIT_565_CFG1,
DPI_OUTPUT_FORMAT_16BIT_565_CFG2,
DPI_OUTPUT_FORMAT_16BIT_565_CFG3,
DPI_OUTPUT_FORMAT_18BIT_666_CFG1,
DPI_OUTPUT_FORMAT_18BIT_666_CFG2,
DPI_OUTPUT_FORMAT_24BIT_888,

output_enable_mode : 0: Output enable is combination of H + V sync 1: Output enable is active only when valid data is being output
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.
output_enable_polarity: 0: Output enable active high 1: Output enable active low.
hsync/vsync/oe phases : 0: Output synchronous with positive edge of the clock 1: Output synchronous with negative edge of the clock
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5083
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by HeBus » Wed Sep 24, 2014 4:23 pm
dom wrote:rgb_order can be one of:
DPI_RGB_ORDER_RGB,
DPI_RGB_ORDER_BGR,
DPI_RGB_ORDER_GRB,
DPI_RGB_ORDER_BRG,

output_format is the config.txt setting dpi_output_format
DPI_OUTPUT_FORMAT_9BIT_666,
DPI_OUTPUT_FORMAT_16BIT_565_CFG1,
DPI_OUTPUT_FORMAT_16BIT_565_CFG2,
DPI_OUTPUT_FORMAT_16BIT_565_CFG3,
DPI_OUTPUT_FORMAT_18BIT_666_CFG1,
DPI_OUTPUT_FORMAT_18BIT_666_CFG2,
DPI_OUTPUT_FORMAT_24BIT_888,

output_enable_mode : 0: Output enable is combination of H + V sync 1: Output enable is active only when valid data is being output
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.
output_enable_polarity: 0: Output enable active high 1: Output enable active low.
hsync/vsync/oe phases : 0: Output synchronous with positive edge of the clock 1: Output synchronous with negative edge of the clock


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.
User avatar
Posts: 6
Joined: Wed Sep 24, 2014 11:38 am
by ceteras » Thu Sep 25, 2014 8:58 pm
I've used an SN74HC04N to invert the DE signal and it worked.
I've got some horizontal jittering on the image, it could be from the inverter chip or from my ~10cm long dpi wires (or maybe the ground layout).
This would make a nice raspberry pi laptop, I believe it's the lowest-power solution for a good LCD screen, so far.
Of course, an arduino could provide all the i/o which were sacrificed in the process.

Edit: I've separated power to lcd display from power to lvds chip and then powered lvds chip from the pi.
Then I've changed all ground connections to go directly to J8 on the pi.
This removed most of the jitter, all that was left was a stable one-pixel jitter, alternating each line, left/right.
After I've reversed the polarity of the pixel clock too, the image is perfectly stable, looking great.
So both PCLK and DE signals' polarity need to be configurable in software.
Posts: 231
Joined: Fri Jan 27, 2012 1:42 pm
Location: Romania
by r1ch999999 » Mon Sep 29, 2014 8:16 pm
As I said on twitter, I'm in for one.
Posts: 5
Joined: Mon Sep 29, 2014 8:07 pm
by J Sanderson » Fri Oct 03, 2014 10:58 am
A few questions, I suspect Gert is the only person who can answer authoritatively to some of them!
1. If you have an SD Image downloaded in the last 4 weeks is it necessary to "Copy the file dt-blob-dpi.bin to boot partition of sdcard, renaming it to dt-blob.bin"?
2. Re 3 or 4 bits per channel use (512 & 4096 colors) Will this need a further update to start.elf? I can't see how to set it up (dpi_output_format?) or what pins they use?
3. How soon if ever might that update be made available.
4. Can Gert confirm that the sync pins used cannot be moved from the I2C pins?
If that is fixed in the hardware we'll just have to live with it, though the BCM2835/PI does keep coming up with little presents 8-)

Thanks for your time. J.
Posts: 30
Joined: Thu Nov 03, 2011 8:59 pm
by Gert van Loo » Fri Oct 03, 2014 8:03 pm
J Sanderson wrote:A few questions, I suspect Gert is the only person who can answer authoritatively to some of them!
1. If you have an SD Image downloaded in the last 4 weeks is it necessary to "Copy the file dt-blob-dpi.bin to boot partition of sdcard, renaming it to dt-blob.bin"?
2. Re 3 or 4 bits per channel use (512 & 4096 colors) Will this need a further update to start.elf? I can't see how to set it up (dpi_output_format?) or what pins they use?
3. How soon if ever might that update be made available.
4. Can Gert confirm that the sync pins used cannot be moved from the I2C pins?
If that is fixed in the hardware we'll just have to live with it, though the BCM2835/PI does keep coming up with little presents 8-)

Thanks for your time. J.


1. To use the VGA you need a newer image (although I don't know the exact version.) You ALWAYS need the "dt-blob-dpi.bin" in the boot partition.
2. I don't think there is a configuration for less bits. Also it is not needed, the system does not care if you don't use some bits.
Beware to always keep the MS bits. I assume your reason is to have more GPIO pins in which case you have to make a new dt-blob.bin which tell the system which GPIO pins you want to use.
3. The update for single screen is already out. I have seen no schedule for the multi-screen version for Rasbian, but I think Dom has pushed it already out for XBMC.
4. Affirmative, it is fixed in the hardware.
User avatar
Posts: 2403
Joined: Tue Aug 02, 2011 7:27 am
by arm2 » Sat Oct 04, 2014 10:27 am
Gert van Loo wrote:1. To use the VGA you need a newer image (although I don't know the exact version.) You ALWAYS need the "dt-blob-dpi.bin" in the boot partition.
2. I don't think there is a configuration for less bits. Also it is not needed, the system does not care if you don't use some bits.
Beware to always keep the MS bits. I assume your reason is to have more GPIO pins in which case you have to make a new dt-blob.bin which tell the system which GPIO pins you want to use.

Re 1. I'm a RISC OS user. Is the dt-blob-dpi.bin run by start.elf before an operating system is loaded?
or is it a linux program and RISC OS would need an equivalent?

Re. 2 To use the lower significant pins as standard GPIO do you just assign them to the appropriate ALT use after they will have been set for DPI earlier in the system booting?

Chris
Posts: 253
Joined: Thu Dec 15, 2011 3:46 pm
by jdb » Sat Oct 04, 2014 11:07 am
arm2 wrote:Re 1. I'm a RISC OS user. Is the dt-blob-dpi.bin run by start.elf before an operating system is loaded?
or is it a linux program and RISC OS would need an equivalent?

Re. 2 To use the lower significant pins as standard GPIO do you just assign them to the appropriate ALT use after they will have been set for DPI earlier in the system booting?

Chris


The devicetree blob is currently parsed for (gpioman) pin settings by start.elf prior to loading whichever OS is present. The pins on boot will be set to the alt-settings requested in the gpio map. In operating systems where DT is supported, the devicetree can be passed through on boot to preload the OS with information about attached hardware, etc.

Poking the alt settings of any GPIO directly can revert it to an input/output.
Rockets are loud.
https://astro-pi.org
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1659
Joined: Thu Jul 11, 2013 2:37 pm
by Burngate » Sat Oct 04, 2014 11:35 am
... and another possibly silly question from another RISC OS user ...
Gert's PDF states:
You select the mode using: dpi_output_format=X (X in range 1..7)
The VGA adaptor PCB is designed up for mode 5.
does this go in config.txt?

And if I choose a different format, with fewer or more bits, I assume I'll have to adjust the GPIO Alt usage myself?
User avatar
Posts: 4825
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by Gert van Loo » Sat Oct 04, 2014 6:59 pm
Burngate wrote:... and another possibly silly question from another RISC OS user ...
Gert's PDF states:
You select the mode using: dpi_output_format=X (X in range 1..7)
The VGA adaptor PCB is designed up for mode 5.
does this go in config.txt?

Yes, it goes in config.txt

And if I choose a different format, with fewer or more bits, I assume I'll have to adjust the GPIO Alt usage myself?

As I said before: for fewer bits you just don't use them and compile a different dt-blob.bin.
BUT! for any configuration which is NOT mode 5, you have to change the adapter hardware as
the MS bits will come out on different pins.
User avatar
Posts: 2403
Joined: Tue Aug 02, 2011 7:27 am
by Burngate » Sun Oct 05, 2014 11:52 am
Gert van Loo wrote:Yes, it goes in config.txt

Thanx
the MS bits will come out on different pins.

Yes, happy with that - not so much for the pins it uses, more the pins it leaves free, as in convenience for wiring other stuff
Untitled.png
Untitled.png (14.94 KiB) Viewed 4159 times
User avatar
Posts: 4825
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by Gert van Loo » Sun Oct 05, 2014 1:39 pm
Interesting anecdote: that colour connection table is NOT in the 2835 datasheet.
I wanted to add that to my document and nobody knew the details.
So I had to ask my ex-colleagues at Broadcom for the original chip Verilog code.
I send an email which went like this:
"Can you send me the DPI colour multiplexing code. It is somewhere in file here.... and it looks like this....."
User avatar
Posts: 2403
Joined: Tue Aug 02, 2011 7:27 am
by J Sanderson » Wed Oct 08, 2014 3:47 pm
Hi I'm going try and build my own. To avoid the problem of drawing more power than the Broadcom specs say you should for the HSYNC and VSYNC I was thinking of using a transistor and the 3v3 line. What value resistor would give the necessary current that the VGA specs say HSYNC and VSYNC?
I've tried finding the specs for VGA but no joy.
Also does the transistor need to be fast?
If yes recommendation welcome.
Posts: 30
Joined: Thu Nov 03, 2011 8:59 pm
by Gert van Loo » Wed Oct 08, 2014 4:04 pm
J Sanderson wrote:Hi I'm going try and build my own. To avoid the problem of drawing more power than the Broadcom specs say you should for the HSYNC and VSYNC I was thinking of using a transistor and the 3v3 line. What value resistor would give the necessary current that the VGA specs say HSYNC and VSYNC?
I've tried finding the specs for VGA but no joy.
Also does the transistor need to be fast?
If yes recommendation welcome.


The VGA sync resistor values where determined very scientifically:
we tried it on three different monitors and lowered the value until it worked with all three. :roll:
If you use a transistor that will invert the polarity.
And if you want a high resolution you need some very fast transistors.
Why not use two small buffers. Look for 'tiny logic'.
User avatar
Posts: 2403
Joined: Tue Aug 02, 2011 7:27 am
by J Sanderson » Wed Oct 08, 2014 4:57 pm
Thanks Gert I look into 'tiny logic'.
Posts: 30
Joined: Thu Nov 03, 2011 8:59 pm
by ceteras » Thu Oct 09, 2014 11:04 am
I don't understand how the sync series resistors were thought.
The RGB signals are 75ohm impedance, but the sync lines are digital logic, and their requirements are pretty much similar to TTL.
That is, a minimum voltage for logic "1" is 2.4V, and maximum voltage for logic "0" is 0.5V. This should safely work with 3.3V GPIO.
Also, the termination inside a VGA monitor should be a 2.2K resistor to +5V, which I don't think could hurt the 3.3V logic.
So, the series resistors on the sync signals can have the role of suppressing the reflections on the sync lines, and thus lower values should not hurt the respective GPIO lines.
Please correct me if/where I'm wrong!

L.E. on another topic:

J Sanderson wrote:Thanks Gert I look into 'tiny logic'.


I would recommend 74LVC2G34 dual gate buffer/repeater for the sync signals.
Posts: 231
Joined: Fri Jan 27, 2012 1:42 pm
Location: Romania
by J Sanderson » Thu Oct 09, 2014 11:49 am
If I've understood the maths and resistor choice I'm going to try:
1 Bit per pixel: use 274 Ohm resistors
2 Bits per pixel: 412 Ohm on MSB and 825 on the other = 275 Ohm
n.b. I don't have any 412s at present so will try: 422 Ohm on MSB and 845 on the other = 281 Ohm

Can anyone confirm if I've calculated it correctly?
Posts: 30
Joined: Thu Nov 03, 2011 8:59 pm
by ceteras » Thu Oct 09, 2014 12:19 pm
It is correct, but for 1bit version, you draw 9.45mA from the RGB pins.
This is not a problem by itself, but you might have to be careful what currents will the other GPIO pins have to source, as there is a limit for the total current on the GPIO bus.
Posts: 231
Joined: Fri Jan 27, 2012 1:42 pm
Location: Romania