I know this has been asked before (http://mbed.org/forum/mbed/topic/1486/?page=1#comment-7333)

But my requirements are alot lower. I want to take a composite video input(pal) and capture 8 pixels every 5 frames. I just would need to know the color as im after controlling a rgb led to match those colors.

Any help would be great,

Thanks David

The problem with PAL is that the colour information is quadrature modulated on a 4.4MHz subcarrier. An LM1881 won't help as it only separates the sync signals from the composite. You would really need a colour decoder with pal delay line and everything to get to the colour information. Is it possible for you to start from an RGB signal? If you only need an 'impression' of the overall colour (for an ambilight like application), you could try to low-pass filter the RGB signals(say between 1 and 10Hz) and sample each of them. If you want to know the colour of a particular screen region you need your sampling to be in sync with the video. This could be e.g. 4 times per line but does not need to be, in fact it could be completely random as long as you know where the sample is coming from. You would then average the samples from each region to get a stable colour value. Averaging is necessary because the low-pass filter now has to be in the order of 50-100kHz.

If you are up for a bit of circuit wrangling, check out the MAX9526 NTSC/PAL Video Decoder. It takes composite video in and spits out high-speed 9-bit data in YCbCR sequence.

You would have to figure out how to pick off the 8 pixels of interest from that firehose of data...

Concerning drinking from the firehose - I might have an approach that involves the question of "how fast can the mbed DMA grab data?". I will require low-level access to the Counter-Timer units, so it probably will not play well with the mbed libraries. Still, it might work with careful C/C++ code.

If I comprehend the PAL standards correctly, the Video Decoder may be pumping out 9 bit samples with a 13.5 MHz clock rate. The basic idea is to run the sample-rate clock to a Counter-Timer external input pin. Program a companion match register to a value of '1' and set the Counter-Timer to both re-set to zero on match, and to trigger a DMA word transfer (from port 2?) to a memory buffer (with destination increment). Wire the 9 Decoder data pins to 9 input pins for the DMA'ed port. This scheme requires the DMA to respond within about 7 cpu-clocks (at 96 MHz).

If the above works as I expect, it should be possible to capture two lines of PAL data to a 4.75Kbyte buffer. The rest of the frame can be used to extract the samples for the 'pixel' of interest, pack the bits into integers, compute the RGB values, re-set the DMA, etc. Which two lines are captured must be controled, but connecting Vsync and Hsync to other input pins for Interrupts, a second Counter, a PWM channel, and a few TTL gates & flip-flops ought to be able to be made to do the job. Or maybe the DMA system can be programed to dump unwanted samples to a single (non-incrementing) memory word via 'linked' buffers. Perhaps a PWM channel could be made to gate the sample clock so that only data from the desired horizontal zone are captured, greatly reducing the required buffer size.

If the DMA cannot complete within 7 cpu-clocks, the gating scheme could still be used to reduce a high-speed capture buffer to a few more TTL gates, counter chips, and a small RAM. Of course, this could all go into a FPGA instead, but the right approach might make the difference between a larger or smaller FPGA, or even a CPLD.

Although this thread discusses ADC/DMA and ADC isn't what you want, the idea of using peripherals and DMA is demoed here:- http://mbed.org/forum/mbed/topic/1965/ and http://mbed.org/forum/mbed/topic/1798

I think DMA is overkill, the guy wants 8 pixels every 5 frames (200ms), when spaced equally that is a sample frequency of 40Hz.

Hi,

From the date you posted this question, I really don't know if it is still an issue for you, but anyway, take a look what I achieved with the LPC1768...

https://youtu.be/fpRAiP_R0XA

I successfully achieved a NTSC/PAL video overlay using timers and input capture capabilities of the LPC1768.

So to your question... It's a matter on how fast can the LPC read an input capture, maybe you may achieve MCK/4 or MCK/8 "pixel" resolution, and that is not 8 "real" pixels at all....

On the other hand, what you may be able to do, using a video OP AMP (that what I'm working on today), is to capture the pixels over some sort of threshold but, nothing to do with color... just black or white output...

cheers