User avatar
rpdom
Posts: 12962
Joined: Sun May 06, 2012 5:17 am
Location: Ankh-Morpork

Re: Gert's VGA add-on for the B+

Sat Jan 17, 2015 7:29 pm

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
Posts: 32
Joined: Wed Feb 12, 2014 4:22 pm

Re: Gert's VGA add-on for the B+

Sat Jan 17, 2015 7:50 pm

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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Sat Jan 17, 2015 8:45 pm

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

                  [email protected]_0_SDA_PIN {
                     type = "internal";
                     number = <28>;
                  };
                  [email protected]_0_SCL_PIN {
                     type = "internal";
                     number = <29>;
                  };
Nevertheless, as suggested I will re-compile and force a HDMI mode in addition.

Fat D
Posts: 32
Joined: Wed Feb 12, 2014 4:22 pm

Re: Gert's VGA add-on for the B+

Sat Jan 17, 2015 10:32 pm

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 {
				[email protected] {polarity = "active_high";	termination = "pull_down";startup_state = "inactive";function = "input";};
				[email protected] {function = "dpi";termination = "no_pulling";drive_strength_mA = <0x8>;};
                                [email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";drive_strength_mA = <0x8>;};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "dpi";termination = "no_pulling";};
				[email protected] {function = "i2c0";termination = "pull_up";};
				[email protected] {function = "i2c0";termination = "pull_up";};
				[email protected] {function = "output";termination = "pull_down";};
				[email protected] {function = "output";termination = "pull_down";};
				[email protected] {function = "input";termination = "no_pulling";polarity = "active_low";};
				[email protected] {function = "output";termination = "no_pulling";};
				[email protected] {function = "pwm";termination = "no_pulling";drive_strength_mA = <0x10>;};
				[email protected] {function = "output";termination = "no_pulling";};
				[email protected] {function = "gp_clk";termination = "pull_down";};
				[email protected] {function = "pwm";termination = "no_pulling";drive_strength_mA = <0x10>;};
				[email protected] {function = "input";termination = "no_pulling";polarity = "active_low";};
				[email protected] {function = "output";termination = "pull_down";};
				[email protected] {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				[email protected] {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				[email protected] {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				[email protected] {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				[email protected] {function = "sdcard";termination = "pull_up";drive_strength_mA = <0x8>;};
				[email protected] {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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Fri Jan 23, 2015 8:39 am

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
Posts: 32
Joined: Wed Feb 12, 2014 4:22 pm

Re: Gert's VGA add-on for the B+

Sat Jan 24, 2015 8:54 pm

PR77 wrote: 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.
Attachments
dt-blob-web.zip
Working device tree
(1.37 KiB) Downloaded 416 times

PR77
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Thu Jan 29, 2015 8:39 pm

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" :D !

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?
Attachments
IMG-20150129.jpg
Screenshot
IMG-20150129.jpg (45.46 KiB) Viewed 8164 times

User avatar
Gert van Loo
Posts: 2478
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: Gert's VGA add-on for the B+

Thu Jan 29, 2015 10:35 pm

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
Posts: 235
Joined: Fri Jan 27, 2012 1:42 pm
Location: Romania

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 12:09 am

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
Image

ross
Posts: 13
Joined: Fri Aug 26, 2011 8:18 pm

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 12:35 am

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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 5:37 am

Gert van Loo wrote: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.
ceteras wrote: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
Image
@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!
ross wrote: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?

User avatar
DougieLawson
Posts: 34195
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 11:14 am

PR77 wrote: @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.
Note:The use of baseball bats for educational purposes is completely disallowed on this forum.

Any DMs sent on Twitter will be answered next month.

ceteras
Posts: 235
Joined: Fri Jan 27, 2012 1:42 pm
Location: Romania

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 2:00 pm

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

Fat D
Posts: 32
Joined: Wed Feb 12, 2014 4:22 pm

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 2:35 pm

PR77 wrote: @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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 8:19 pm

DougieLawson wrote:
PR77 wrote: @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.
Gert van Loo wrote: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 wrote: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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 8:25 pm

Fat D wrote: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
Posts: 32
Joined: Wed Feb 12, 2014 4:22 pm

Re: Gert's VGA add-on for the B+

Fri Jan 30, 2015 11:02 pm

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
Posts: 3824
Joined: Thu Mar 27, 2014 2:42 pm
Location: London, UK

Re: Gert's VGA add-on for the B+

Tue Feb 03, 2015 12:02 am

Is the Gert VGA compatible with the pi2?
Doug.
Building Management Systems Engineer.

User avatar
DougieLawson
Posts: 34195
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

Re: Gert's VGA add-on for the B+

Tue Feb 03, 2015 12:18 am

BMS Doug wrote: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).
Note:The use of baseball bats for educational purposes is completely disallowed on this forum.

Any DMs sent on Twitter will be answered next month.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5171
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Gert's VGA add-on for the B+

Tue Feb 03, 2015 12:46 am

DougieLawson wrote: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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Wed Feb 04, 2015 12:19 pm

Fat D wrote: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
Posts: 32
Joined: Wed Feb 12, 2014 4:22 pm

Re: Gert's VGA add-on for the B+

Wed Feb 04, 2015 7:50 pm

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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Wed Feb 04, 2015 8:42 pm

Fat D wrote: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

[email protected]:~# 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 ( :shock: ) 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.jpg
D_CLK
D_CLK.jpg (49.64 KiB) Viewed 7671 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.jpg
Washed Out LCD
Washed Out LCD.jpg (42.26 KiB) Viewed 7671 times
Lastly, my config.txt file.
config.txt.zip
Config.txt
(892 Bytes) Downloaded 403 times

Fat D
Posts: 32
Joined: Wed Feb 12, 2014 4:22 pm

Re: Gert's VGA add-on for the B+

Thu Feb 05, 2015 6:54 pm

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
Posts: 26
Joined: Tue Jan 06, 2015 9:11 pm
Location: Germany

Re: Gert's VGA add-on for the B+

Fri Feb 06, 2015 9:27 pm

Fat D wrote: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! :cry: 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! :(

Return to “HATs and other add-ons”