Hi, All!

Before Christmas I asked you all for ideas and suggestions
on a video capture device I was planning to design.

Within the holiday I had a working design. At least almost working.

In short this is how the design works:

An AD converter gets the videosignal (continually)
The AD's output is connected to a 1 Mbit SRAM.
The board has a 10 MHz crystal oscillator. This is fed directly
to the 16C84 and a counter which divides it to 5 MHz.
The 5 MHz signal clocks the AD and two ripple counters that address
the RAM.

There is also a videosyncseparator that is connected to the PIC.
One signal is the vertical sync and the other is the horizontal sync.
(Horizontal sync is connected to RB0)
Horiz sync has a frequency of 15625 Hz and vertical sync is at 50 Hz.

The PIC controls everything via buffers since speed is important.
When the PIC starts a capture it enables the different IC's via buffers, and
this works ok.

The sequence is as follows:

The PIC gets a start signal from the PC (via the parallell port)
Then it waits for a vertical sync pulse (frame start)
When this occurs the RB0 interrupt is enabled.
The ISR then waits a couple of uS and then it enables
sampling and RAM addressing. Then it waits until the line
is finished (approx 50 uS, this is a fixed delay) before
it disables sampling and RAM addressing.

The main program runs in a waiting loop that checks
for the next vertical sync pulse. When this happens
the interrupt is disabled.

Data is then transferred to the PC over the parallell port.

Now I can get to the problem.... (After a rather lengthy explanation..)

The resulting picture is almost ok....
Starting at some random line the next 134 lines is left-adjusted
exactly two pixels. Then the next 134 lines is left-adjusted two pixels,
and so on. The spacing between the errors is always 134 lines...

Two pixels translates into 400 nS (in this case) and this is also
the PIC's instruction cycle time....

It would seem that the time from the horiz sync pulse occurs
to the ISR starts executing is varying. This must be related to
interrupt latency and some relationship between the 15625 Hz signal
and the 2.5 MHz "sampling rate" of the INTF flag in the PIC.

How can I make sure that the interrupt latency is constant throughout
the entire frame?


-Oyvind     oyvind.kaurstad@nofac.abb.no