Gert's VGA add-on for the B+

[rpdom]

So it looks like currently you are limited to just the one custom mode, which could be used for dpi/hdmi. I wonder if you could use the custom mode for dpi and a standard mode for hdmi and v.v.?

[Fat D]

I do not see anything that would go into the way of it. I also do not know what happens with multiple hdmi_cvt lines. I only know that the Pi refuses to boot with DPI mode DMT_87 and no hdmi_cvt.

[PR77]

Gents, thanks for your feedback! Will find some time tomorrow to get stuck into it again.

P.S., when modifying the DT DTS I removed the other nodes which are also using I2C Port 0;

Code: Select all

                  pin_define@CAMERA_0_SDA_PIN {
                     type = "internal";
                     number = <28>;
                  };
                  pin_define@CAMERA_0_SCL_PIN {
                     type = "internal";
                     number = <29>;
                  };

Nevertheless, as suggested I will re-compile and force a HDMI mode in addition.

[Fat D]

Just for reference, these are my files with which I could get an Adafruit 5" DPI screen working:
config.txt:

Code: Select all

enable_dpi_lcd=1
dpi_output_format=458759
hdmi_cvt=800 480 60 6
dpi_group=2
dpi_mode=87
#dpi_mode=4
#dpi_mode=9
#dpi_group=1
#dpi_mode=3
display_default_lcd=1

All below the stock Raspbian stuff, plus the disable_overscan bit uncommented. I do not know if the invert flags in the output format are all necessary, but oe_polarity was. By the way, I am using the 24-bit mode 7, but it looks like the display does not provide 8-bit resolution on all channels, I see some discretization on my test gradients. Or is that a limitation of the Pi?
DT Source:

Code: Select all

			pin_config {
				pin@default {polarity = "active_high";	termination = "pull_down";startup_state = "inactive";function = "input";};
				pin@p0 {function = "dpi";termination = "no_pulling";drive_strength_mA = <0x8>;};
                                pin@p1 {function = "dpi";termination = "no_pulling";};
				pin@p2 {function = "dpi";termination = "no_pulling";drive_strength_mA = <0x8>;};
				pin@p3 {function = "dpi";termination = "no_pulling";};
				pin@p4 {function = "dpi";termination = "no_pulling";};
				pin@p5 {function = "dpi";termination = "no_pulling";};
				pin@p6 {function = "dpi";termination = "no_pulling";};
				pin@p7 {function = "dpi";termination = "no_pulling";};
				pin@p8 {function = "dpi";termination = "no_pulling";};
				pin@p9 {function = "dpi";termination = "no_pulling";};
				pin@p10 {function = "dpi";termination = "no_pulling";};
				pin@p11 {function = "dpi";termination = "no_pulling";};
				pin@p12 {function = "dpi";termination = "no_pulling";};
				pin@p13 {function = "dpi";termination = "no_pulling";};
				pin@p14 {function = "dpi";termination = "no_pulling";};
				pin@p15 {function = "dpi";termination = "no_pulling";};
				pin@p16 {function = "dpi";termination = "no_pulling";};
				pin@p17 {function = "dpi";termination = "no_pulling";};
				pin@p18 {function = "dpi";termination = "no_pulling";};
				pin@p19 {function = "dpi";termination = "no_pulling";};
				pin@p20 {function = "dpi";termination = "no_pulling";};
				pin@p21 {function = "dpi";termination = "no_pulling";};
				pin@p22 {function = "dpi";termination = "no_pulling";};
				pin@p23 {function = "dpi";termination = "no_pulling";};
				pin@p24 {function = "dpi";termination = "no_pulling";};
				pin@p25 {function = "dpi";termination = "no_pulling";};
				pin@p26 {function = "dpi";termination = "no_pulling";};
				pin@p27 {function = "dpi";termination = "no_pulling";};
				pin@p28 {function = "i2c0";termination = "pull_up";};
				pin@p29 {function = "i2c0";termination = "pull_up";};
				pin@p31 {function = "output";termination = "pull_down";};
				pin@p32 {function = "output";termination = "pull_down";};
				pin@p35 {function = "input";termination = "no_pulling";polarity = "active_low";};
				pin@p38 {function = "output";termination = "no_pulling";};
				pin@p40 {function = "pwm";termination = "no_pulling";drive_strength_mA = <0x10>;};
				pin@p41 {function = "output";termination = "no_pulling";};
				pin@p44 {function = "gp_clk";termination = "pull_down";};
				pin@p45 {function = "pwm";termination = "no_pulling";drive_strength_mA = <0x10>;};
				pin@p46 {function = "input";termination = "no_pulling";polarity = "active_low";};
				pin@p47 {function = "output";termination = "pull_down";};
				pin@p48 {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				pin@p49 {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				pin@p50 {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				pin@p51 {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				pin@p52 {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				pin@p53 {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
			};
 

under pins_bplus. I removed whitespace compared to the version I had. Comments are also gone, due to the fact that I decompiled the blob instead of redownloading the source. Which is also why the version I used had an awful lot of whitespace. pin_defines are unchanged. The blob version is attached. I prefer to keep the camera I²C configured due to the fact that I plan to abuse the camera connector as GPIO now that the main header is all used up, and I need an I²C for things like a touchscreen controller and possibly some other input. I have an FPC-to-wires cable all soldered up, I just need to attach connectors.


Also, any news on HDMI/DPI dual screen support? I have not seen any documentation on it and I only have one framebuffer device available.

Edit: I cannot upload the file here, sorry about that.

[PR77]

Quick update for those following. Still no action on my LCD. In fact I seem to have taken several steps backwards and have no activity on the DPI. I now can't see the RGB signals jumping about.

I am still using a SD Card with RISC OS (I only have a 2GB micro SD available) but I would _assume_ that it makes no difference as the DPI is control and configured with the Bootloader.bin / Start.elf and not the Kernal.img.

Questions:

1. Is it possible to have a different resolution on the DPI and HDMI? I don't see anything on the HDMI during my experiments however when I disable the DPI the HDMI springs to life.

2. Is there a way to know if the Pi has booted successful if I have no video signal? If there some firmware which flashes an LED?

Will keep you posted. Thanks!

[Fat D]

I am still using a SD Card with RISC OS (I only have a 2GB micro SD available) but I would _assume_ that it makes no difference as the DPI is control and configured with the Bootloader.bin / Start.elf and not the Kernal.img.

This may very well matter, I would recommend testing it. I could imagine the display driver needs to support the DPI registers.
I was able to attach a packed copy of the DT Blob (renamed because I am juggling different versions); if you want to try it, go ahead. I have tested it with the latest Raspbian image and that worked.

[PR77]

Fat D, thanks for the blob that has helped me a lot. I can now see am image on my screen and after abut a day tweaking with the dpi_output_format I have the image correctly aligned to the physical screen layout.

However! The screen does not seem to be displaying the RGB correctly and the colours are swapped. I've checked all the signal lines and they are correct. With the standard Raspbian boot sequence the background is white and I would expect it to be black. So it is unlikely a mix up of the RGB signals. I was checking the LCD datasheet and the Typ. D_CLK is 7.5Mhz and when probing the clock from the Pi it is at 31Mhz. I'm thinking I have a clocking issue. All of the content on the display (text and raspberry logo) are correctly formatted and looking really nice. Just the colours are out.

I was having a play with hdmi_timings to see if I could adjust the pixel clock to slow it down, however with a custom config (shown below) the Pi doesn't boot. I'm thinking the firmware has detected a "user error" !

Code: Select all

enable_dpi_lcd=1
dpi_output_format=4456965
#hdmi_cvt=400 240 60 6 0 0 0
#hdmi_cvt=480 272 60 3 0 0 0
hdmi_timings=400 0 1 2  2 240 0 2 4  2 0 0 0 60 0 9600000 6
#hdmi_timings= 480 0 1 41 2 272 0 2 10 2 0 0 0 60 0 9009000 3
dpi_group=2
dpi_mode=87
display_default_lcd=1

Note #1: Only when I use the hmdi_cvt 400x240 string the display "works" even though the colours are not correct. All other configs result in no booting.

Note #2: The reason there is a 480x272 setup is because I was trying something from the customer modes thread to determine if the firmware checks the parameters for consistency;

http://jp.raspberrypi.org/forums/viewto ... 29&t=24679

Any ideas?

[Gert van Loo]

I see green were it should be red
I see blue where it should be green
I see white where it should be black.
All signals need to be inverted?
There maybe the possibility of a LCD colour look-up table but I am not sure if that is usable in this situation.
I have to ask an expert at Pi headquarters.

[ceteras]

There are different shades of all colours on the boot screen and this makes it more difficult.
An rgb screen test like this image would help a lot more: http://1zelda.com/tv/pics/rgb_test.jpg

[ross]

Can you describe what configuration / data (if any) you are setting up the panel with over I2C? Do you have a URL for the datasheet? (ideally the one with the command set of the panel)

My first guess is that trying to toggle any "display invert set" command might help (a W.A.G. of sending command 20h or 21h to toggle this)

[PR77]

I see green were it should be red
I see blue where it should be green
I see white where it should be black.
All signals need to be inverted?
There maybe the possibility of a LCD colour look-up table but I am not sure if that is usable in this situation.
I have to ask an expert at Pi headquarters.

@Gert, The RGB signals for the LCD are active high and sampled on the falling edge of the D_CLK. I have checked this with a CRO (do you still use this word or oscilloscope is the way to go?) and it appears to be OK. I was thinking of a D_CLK sync issue as the D_CLK seems faster than what the LCD can handle and it may be sampling the pixel data at the wrong point.

There are different shades of all colours on the boot screen and this makes it more difficult.
An rgb screen test like this image would help a lot more: http://1zelda.com/tv/pics/rgb_test.jpg

@ceteras, good suggestion. I will try this. As I don't have X installed it may take a little longer to test this as I need to figure out how to display a picture with it. I'm far from a Linux guru!

Can you describe what configuration / data (if any) you are setting up the panel with over I2C? Do you have a URL for the datasheet? (ideally the one with the command set of the panel)

My first guess is that trying to toggle any "display invert set" command might help (a W.A.G. of sending command 20h or 21h to toggle this)

@Ross, the LCD is a RAW panel with no I2C interface. It has RGB, H+V Sync, DE and CLK. It is from the SHARP LQ050 family of panels.

Any idea's with the hdmi_settings issue?

[DougieLawson]

@ceteras, good suggestion. I will try this. As I don't have X installed it may take a little longer to test this as I need to figure out how to display a picture with it. I'm far from a Linux guru!

cd /tmp
wget http://1zelda.com/tv/pics/rgb_test.jpg
fbi rgb_test.jpg

You may need to get that with sudo apt-get install fbi but that's easier than getting X running.

[ceteras]

If the image is inverted, it would be like this:
- cyan instead of red
- magenta instead of green
- yellow instead of blue

[Fat D]

@Gert, The RGB signals for the LCD are active high and sampled on the falling edge of the D_CLK. I have checked this with a CRO (do you still use this word or oscilloscope is the way to go?) and it appears to be OK. I was thinking of a D_CLK sync issue as the D_CLK seems faster than what the LCD can handle and it may be sampling the pixel data at the wrong point.

Unlikely. All data for each individual pixel is transferred in parallel (this is why over 24 pins are needed), so screwed colors are not what you would expect from clock issues, much less almost exactly inverted color. My guess is like Gert's, that the display requires opposite polarity on the color lines for some weird reason, but the only datasheet I found seems to contradict that. Is there anything connected between the Pi pins and the display pins?. But if you want to reduce the pixel clock, what you might try is reducing the refresh rate and the blanking interval in your CVT config. I have not tried it myself (no fast scope at hand), but given that DPI is essentially a digital version of analog video, that should work.
As for the test picture, do what Dougie said - use fbi.

Let us do the math for the pixel clock. Your display is 400x240, the refresh rate you have it set to amounts to 60 Hz. Disregarding blanking intervals for now, that means that in order to get every pixel out for every frame, your pixel clock is no smaller than 400*240*60 Hz = 5.76 MHz. Seems within spec for now. However, CVT introduces an additional 96 pixels of horizontal blanking and 16 lines of vertical blanking. That results in 496*256*60=7.something MHz, right on target. Reduced blanking instead fixed blanking pixel count irrespective of resolution, so it actually increases the blanking interval for such small screens. Anyway, there should be no reason for the Pi to output such high frequencies to begin with at your resolution, so something is off with your setup.

[PR77]

@ceteras, good suggestion. I will try this. As I don't have X installed it may take a little longer to test this as I need to figure out how to display a picture with it. I'm far from a Linux guru!

cd /tmp
wget http://1zelda.com/tv/pics/rgb_test.jpg
fbi rgb_test.jpg

You may need to get that with sudo apt-get install fbi but that's easier than getting X running.

@Dougie, thanks. This has worked and I was able to download and view the JPG.

I see green were it should be red
I see blue where it should be green
I see white where it should be black.
All signals need to be inverted?
There maybe the possibility of a LCD colour look-up table but I am not sure if that is usable in this situation.
I have to ask an expert at Pi headquarters.

If the image is inverted, it would be like this:
- cyan instead of red
- magenta instead of green
- yellow instead of blue

@Gert and Ceteras, thanks also. After viewing the JPG it is easy to see that the colours are inverted as suggested. However this is not consistent with the datasheet as far as I am aware. Basically the LCD is;

Black when RGB{0...5} = 0 0 0
Blue when RGB{0...5} = 0 0 1
Green when RGB{0...5} = 0 1 0
Cyan when RGB{0...5} = 0 1 1
Red when RGB{0...5} = 1 0 0
Magenta when RGB{0...5} = 1 0 1
Yellow when RGB{0...5} = 1 1 0
White when RGB{0...5} = 1 1 1

This is what I was expecting from the DPI, the RGB bits a logic low of dark pixels and logic high for illuminated pixels.

[PR77]

Unlikely. All data for each individual pixel is transferred in parallel (this is why over 24 pins are needed), so screwed colors are not what you would expect from clock issues, much less almost exactly inverted color. My guess is like Gert's, that the display requires opposite polarity on the color lines for some weird reason, but the only datasheet I found seems to contradict that. Is there anything connected between the Pi pins and the display pins?. But if you want to reduce the pixel clock, what you might try is reducing the refresh rate and the blanking interval in your CVT config. I have not tried it myself (no fast scope at hand), but given that DPI is essentially a digital version of analog video, that should work.
As for the test picture, do what Dougie said - use fbi.

Let us do the math for the pixel clock. Your display is 400x240, the refresh rate you have it set to amounts to 60 Hz. Disregarding blanking intervals for now, that means that in order to get every pixel out for every frame, your pixel clock is no smaller than 400*240*60 Hz = 5.76 MHz. Seems within spec for now. However, CVT introduces an additional 96 pixels of horizontal blanking and 16 lines of vertical blanking. That results in 496*256*60=7.something MHz, right on target. Reduced blanking instead fixed blanking pixel count irrespective of resolution, so it actually increases the blanking interval for such small screens. Anyway, there should be no reason for the Pi to output such high frequencies to begin with at your resolution, so something is off with your setup.

This is nothing connected in-between the DPI of the Pi and the LCD. I have connected the two together via an Adafruit T-Cobbler and good quality pinned jumper cables.

I changed the refresh rate in the CVT to 50Hz and I see a D_CLK change but anything lower than this the D_CLK stops oscillating and remained fixed high.

EDIT: The D_CLK pin actually does show a short burst of activity for about 3.4ms and it looks like an I2C Clock signal. Even though the DPI is enabled does the Pi still look for a HAT?

I did notice that when probing the D_CLK with my CRO the LCD washed out and the colours appears normal! However the LCD was not very clear and the image not stable. I need to come to the bottom of this D_CLK issue. It may not be the root cause but it is fundamentally incorrect.

[Fat D]

Do you have gpio_list installed?
https://github.com/rewolff/bw_rpi_tools ... aster/gpio
If so, does it report ALT2 for the first 27 GPIOs when you execute it?
How clear is the 31 MHz trace and what levels does it have? A photo might be nice if you can provide one. Also, the complete config.txt that gives you the whited-out picture. Mind you, I am grasping for straws here.

[BMS Doug]

Is the Gert VGA compatible with the pi2?

[DougieLawson]

Is the Gert VGA compatible with the pi2?

I'd guess "Yes". The GPU is identical, the pins are identical, the ARM7 can run ARM6 code, the kernel for the PI2 is 3.18.5+ built for ARM7 (probably to gain some go faster stripes).

[dom]

I'd guess "Yes". The GPU is identical, the pins are identical, the ARM7 can run ARM6 code, the kernel for the PI2 is 3.18.5+ built for ARM7 (probably to gain some go faster stripes).

It's a good guess. I've tested Gert's VGA adapter on Pi2 and it works just fine.

[PR77]

Do you have gpio_list installed?
https://github.com/rewolff/bw_rpi_tools ... aster/gpio
If so, does it report ALT2 for the first 27 GPIOs when you execute it?
How clear is the 31 MHz trace and what levels does it have? A photo might be nice if you can provide one. Also, the complete config.txt that gives you the whited-out picture. Mind you, I am grasping for straws here.

Ok. I installed gpio_list and from memory most of the initial pins were ALT2 (when trying to access the forum at home in the evening it is blocked for me so I'm going from memory). The 31 MHz signal is fairly sinusoidal (my CRO is 100 MHz @ 1Gs/s). I will post some pictures of the D_CLK and the washed-out screen when I probe the D_CLK. After probing the D_CLK the colours are still washed-out but I can clearly see some green, black and red text correctly displayed.

I will also post the config.txt with the configurations that do not generate a picture at all (and no DPI signal activity).

[Fat D]

I am most interested in the first two or four GPIOs, because they are where the magic happens. The rest just colors things.
A sinusoidal output on a Pi GPIO seems strange. Either you have way too much reactance on the bus, something resonant is connected there or there is a high impedance somewhere and you are picking up crosstalk. What are the peak values of the sinusoid?
Makes me wish I had my own scope so I could cross-check before talking so confidently about how things should be.
Also, why does a CRO have a sample rate?

[PR77]

I am most interested in the first two or four GPIOs, because they are where the magic happens. The rest just colors things.
A sinusoidal output on a Pi GPIO seems strange. Either you have way too much reactance on the bus, something resonant is connected there or there is a high impedance somewhere and you are picking up crosstalk. What are the peak values of the sinusoid?
Makes me wish I had my own scope so I could cross-check before talking so confidently about how things should be.
Also, why does a CRO have a sample rate?

Ok, so I've check the GPIO modes and the necessary pins are ALT2.

Code: Select all

root@raspberry-pi:~# sudo ./gpio_list 
   0    ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 
  10    ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 
  20    ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT2 ALT0 ALT0 
  30     INP  OUT  OUT  INP  INP  INP  INP  INP  OUT  INP 
  40    ALT0  OUT  INP  INP ALT0 ALT0  INP  OUT ALT3 ALT3 
  50    ALT3 ALT3 ALT3 ALT3  INP 

Here is the D_CLK from my CRO (TDS220 Digital Oscilloscope hence the sample rate) which shows that it is a little strange. Pk-Pk is about 5.4 volts ( ) but the negative undershoot contributes to that. I've tried loading the output with an inline 220 Ohm resistor and even an external pull-up / pull-down, no change.

D_CLK

D_CLK.jpg (49.64 KiB) Viewed 9611 times

When I probe the D_CLK with my Hi-Z x10 CRO probe, the display washes out and the colours appear slightly "normal".

Washed Out LCD

Washed Out LCD.jpg (42.26 KiB) Viewed 9611 times

Lastly, my config.txt file.

config.txt.zip

Config.txt

(892 Bytes) Downloaded 425 times

[Fat D]

That trace looks awful. Again, I wish I knew what my working trace looked like.
I see nothing wrong with config and pin mux. One more idea: What kind and length of cables are there between the Pi and the screen. I am running lots of 10 cm jumper wires to a breadboard to a breakout to a 30 cm FPC extension to the screen's input FPC no problem, but the more you reveal about your setup, the stranger it gets.
Also, that looks like a DSO to me, not a CRO. Which explains the sample rate.

[PR77]

That trace looks awful. Again, I wish I knew what my working trace looked like.
I see nothing wrong with config and pin mux. One more idea: What kind and length of cables are there between the Pi and the screen. I am running lots of 10 cm jumper wires to a breadboard to a breakout to a 30 cm FPC extension to the screen's input FPC no problem, but the more you reveal about your setup, the stranger it gets.
Also, that looks like a DSO to me, not a CRO. Which explains the sample rate.

I'm connecting to the Pi with an Adafruit T-Cobbler inserted into a new breadboard. Then from the breadboard I have 15cm good quality jumpers with proper pins and receptacles. These jumper wires connect to a 0.1mil header on a FPC adapter board. All buzzed out ok.

I've stripped the setup down to the minimum and I am now only probing the Pi. The D_CLK is still bad! The RGB and other control signals seem OK; nice edges (little bit of ringing, but I have no series resistors) and at a frequency more inline with what I would expect.

I'm now wondering if I have damaged my Pi! Is there a service mode which can do a boundary scan of the GPIO (and peripheral) blocks to determine if they are OK? I have another Pi available but I would like to hold off potentially killing that also.

EDIT: Just checked another Pi... Same story!