You didn't say what is your pixel clock or how many pixel across the screen you wish to display. What is your horizontal scan frequency? Do you have another monitor you can try? Maybe one with lower resolution, 1024 x 768 or even 640 x 480?
I have a problem with 1440 being not easily divisible into 640.

 

my pixel clock is equal to 64MHz / ((4 cycles)*2 instructions) = 8 MHz.

 

Could you show me how you connect your vga pins (hardware only). So could you tell me exactly what pins you use and ones you do not. Thanks.

 

For testing, I just connected the RED, GREEN and BLUE inputs together to give me WHITE pixels. The 3V output from the MCU is a bit too much so you may want to attenuate it to about 1V.
This is only for testing. For the final installation you will want to pair the signal with its proper GND using RG-174 coax cable.

 

I believe my problem is hardware because i tested my hardware with a working vga software tester and I still got jitter issues. I am going to make sure everything is perfect for hardware and do a retest. Hopefully this works wish me luck because this may be my last try at getting this to work!!!

 

I redid the hardware carefully and i still got the same jittering. Roman Black-- i know you have done this before and I was wondering if you could try taking my code and putting it on your pic and seeing if you get jittering problems. I know this is asking a lot but it would help to confirm my problems. VSYNC is RB0,HSYNC is RA7 and for simplicity RA0 is the pixel clock. I actually implemented a 6 bit DAC but you only need to test one pixel bit to see if its jittering or not. Here is the url where my code is posted. I couldnt paste it here because it is too large. https://sites.google.com/a/my.uri.edu/captain-pesh/

 

Sorry Peter I'm too busy. Normally I make some time for the forum while I am eating or prepping dinner, or snacking etc, or sometimes just before bed, but I really don't have time now for code testing in hardware. The original VGA plug and wires I made up was all stripped apart when the project was done so I would have to find a VGA plug again and solder all the test setup and wires again etc, it's too much.

I'm still thinking (like MrChips) this may be an issue with your monitor. Can you just plug another monitor in and test that? Otherwise one test I did was to generate the hsync pulses in a loop with a pixel after a hsync pulse, (all the vertical stuff disabled) and then check on a 'scope that the hsync freq was rock solid and the "pixel" was solid and a fixed time after the hsycn pulse.

Since your jitter happens on some hlines and not others (ie is nothing to do with vert), if it is your code or hardware that should be visible on the scope.

Also, the scope will help you test/tune the hsync freq you are generating making sure it is the required 31469 Hz or very close to it. I still think it might be something related to generating a frequency that is not right (assuming you are generating a signal with no jitter).

 

Is it possible my pixel clock is executing colors in between pixel areas? Another words is it possible that jittering could occur if your pixel clock is executing colors between two pixels so sometimes one pixel turns on and then the other. Or does the lcd not care if your pixel clock is not divisible by 25.175MHz?

 

This is what I was wondering. If you took a lupe or magnifing glass and looked at the jitter very closely, is the jitter only one pixel wide (the three RED, GREEN, BLUE dots) or does it spread over more than one pixel?

That is why I suggest trying a different monitor that is not 1400 x 900 resolution.

I'm trying to find info on this problem. Here is one link:

http://en.wikipedia.org/wiki/Native_resolution

 

I tried this monitor http://www.monitorworld.com/Monitors/viewsonic/viewsonice655.html

This monitor is 1280*1024 and I still got jittering but not nearly as bad. Only when I put my eyes close to the screen I get a picture that looks like it is moving or wavy. It kind of gives me a sense that the screen is 3D kind of like how they overlay one image over the other but slightly off. Next thing I am going to do is test with different colors to see if it looks worse.

 

Is it possible my pixel clock is executing colors in between pixel areas? Another words is it possible that jittering could occur if your pixel clock is executing colors between two pixels so sometimes one pixel turns on and then the other. Or does the lcd not care if your pixel clock is not divisible by 25.175MHz?

It's possible, and that would depend on the LCD internals. It has to do some internal processing to go from the 640x480 input to light up its screen pixels of 1400x900.

From my limited VGA experience, I used a 1024x768 VGA LCD and it worked perfect at 640x480, and a newer 1280x1024 VGA LCD which also worked perfect with the PIC generated 640x480.

However there were some jitter and issues when my PIC generated 640x480 hsync was not at the correct frequency. Did you check your hsync freq with a frequency meter or 'scope yet?

 

Peter, with all due respect, RB and I are doing our best to help resolve this problem. But on many occasions you appear to withhold information or don't follow up with suggestions.

I have asked:

1) What is your pixel clock? (I know you told us)
2) What is your horizontal scan frequency?
3) How many pixels across the screen are you trying to display?

RB has asked, have you checked your scan frequency with a frequency meter?
I have asked, do you have a scope? Have you checked the stability of the video signal or clock with reference to the HSYNC signal using a scope?

We still have not established if the jitter is a result of variation in the generated signal or if it is the LCD not dithering the pixels properly.

We're here to help.

 

Monitor: HannsG HW173D, 1440x900 max resolution
Pixel Clock: 8 MHz
HSYNC: 31.465KHz
VSYNC: 59.6Hz
202 pixels to be displayed across one hsync draw

The pixel clock was calculated based on microcontroller code. The hsync and vsync were measured by a multimeter with frequency measuring capabilities.

This video shows the pixel jitter.
http://www.youtube.com/watch?v=0EZi47fV74Y&feature=youtu.be

My oscilloscope shots are attached and the title of each video describes them. I noticed the pixel clock is not a square wave and looks analogue. Possibly an issue?

Let me know if any other information will help.

 

It appears that we have all been running around in circles. Sometimes it helps to know the right questions to ask (on my part).
From a previous post (#42) you hinted that the internal clock is 64MHz.
The spec sheet for PIC18FXX2 I have looked at says the max frequency is 40MHz unless you are using a 64MHz PIC.
What is your XTAL frequency?
I presume you are using a 10MHz or 16MHz xtal and the PLL is multiplying this by 4.
The spec sheet says that the PLL clock jitter is 2%. After all this, maybe this is the problem. Can you replace the xtal with an external 64MHz xtal module? This would clinch whether or not the problem is caused by PLL jitter.

 

I am not using a crystal. I am setting the HFINTOSC to 16MHz then using the PLL to multiply the HFINTOSC by 4. This results in a 64MHz internal.

Should I try setting the frequency with an 16MHz oscillator (don't have) then using the PLL to get 64 MHz?

The other solution you suggested about using a 64MHz oscillator to set the internal frequency is another good idea but is that possible? I will check this.

I am starting to think that even though the pic is capable of driving a 64MHz clock speed it isn't necessarily that accurate. I noticed my pixel clock looks more like a triangle wave rather than a square wave. I have seen this occur when using say cmos 4000 series when you start using frequencies around 1 MHz or greater. The output starts lagging and can't keep up with the changes of the input and results in a triangular output rather than the expected square output.

PIXEL CLOCK:

 

Measuring on my screen with a ruler(!) your sync pulse seems to have a duty of about 15/128 mm or about 11.7%. The proper hysync pulse should be 3.77uS pulse at a hsync total period of 31.77uS, which would be a duty cycle of 3.77/31.77 which is 11.8%. So that looks ok, but we can't tell your period without a freq meter.

MrChips; The PIC cannot accept a 64MHz input, it needs the PLL to get that type of speed. I still don't think the HSPLL is anything to do with the jitter.

But that very rounded looking pixel video output signal is another matter! Why is it so bad and not a nice square wave? The LCD needs to convert that pixel video information to its nearest screen pixel, and a slowly changing waveform like that could well be causing som issues.

 

I don't see what a pixel clock is for anyway, if all the timing comes from the Hsync pin. I thought VGA was analog in terms of the way the colors are sent to it during any given scan line. But if "pixel clock" means the output that turns the trace on or off to generate stripes, that's different.

If the shape of the waveform matters, could it be that the scope you're using hasn't got enough high-frequency response to show a square wave at that frequency, so it's rounding off the edges?

 

I don't see what a pixel clock is for anyway, if all the timing comes from the Hsync pin. I thought VGA was analog in terms of the way the colors are sent to it during any given scan line. But if "pixel clock" means the output that turns the trace on or off to generate stripes, that's different.

There is no physical pixel clock. The value of the pixel clock tells me the width of the pixel.

If the shape of the waveform matters, could it be that the scope you're using hasn't got enough high-frequency response to show a square wave at that frequency, so it's rounding off the edges?

Agreed.

I am not using a crystal. I am setting the HFINTOSC to 16MHz then using the PLL to multiply the HFINTOSC by 4. This results in a 64MHz internal.

Then I would say that this is definitely one source of the problem, if not the only one.

 

My project also used the HSPLL (but at 40MHz not 64MHz) but the clock pulses and all frequencies generated were rock solid, as was the VGA output. I'm just not buying the idea that the HSPLL is causing any timing issue that is making the LCD jitter.

I still think it's down to noise, or an inaccurate frequency, or possibly bad wiring (high capacitance cabling etc).

 

My project also used the HSPLL (but at 40MHz not 64MHz) but the clock pulses and all frequencies generated were rock solid, as was the VGA output.

Did you use an external 10MHz crystal then used the HSPLL to make the internal clock 40MHz? Or did you not use a crystal at all?