Searching \ for '[EE] pixel capturing' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=pixel+capturing
Search entire site for: 'pixel capturing'.

Exact match. Not showing close matches.
PICList Thread
'[EE] pixel capturing'
2006\05\12@132040 by Harold Hallikainen

face picon face
I'm looking at an application where I have 10 bit parallel data
(representing image pixels) flying by at about 27M words per second. I'd
like to capture particular words (under pic control, of course). About the
only thing I can think of is a really fast synchronous counter (19 bits)
driving a binary comparator driving a latch. To get this speed, I'd
probably have to throw it onto an FPGA. Does anyone have any other ideas
or comments? Does a single chip frame buffer exist that would capture this
and let me look at particular pixels using spi? Other ideas?

THANKS!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertise on
hallikainen.com - $100/year!

2006\05\12@152034 by Herbert Graf

flavicon
face
On Fri, 2006-05-12 at 10:19 -0700, Harold Hallikainen wrote:
> I'm looking at an application where I have 10 bit parallel data
> (representing image pixels) flying by at about 27M words per second. I'd
> like to capture particular words (under pic control, of course). About the
> only thing I can think of is a really fast synchronous counter (19 bits)
> driving a binary comparator driving a latch. To get this speed, I'd
> probably have to throw it onto an FPGA. Does anyone have any other ideas
> or comments? Does a single chip frame buffer exist that would capture this
> and let me look at particular pixels using spi? Other ideas?

At only 27MHz and 10 bits of data a CPLD is a viable solution.

I've used the 9536 CPLD with good success, my logan project uses it (and
connects it to a PIC):
http://repatch.dyndns.org:8383/pic_stuff/logan

TTYL

2006\05\12@154032 by Mike Harrison

flavicon
face
On Fri, 12 May 2006 15:21:27 -0400, you wrote:

>On Fri, 2006-05-12 at 10:19 -0700, Harold Hallikainen wrote:
>> I'm looking at an application where I have 10 bit parallel data
>> (representing image pixels) flying by at about 27M words per second. I'd
>> like to capture particular words (under pic control, of course). About the
>> only thing I can think of is a really fast synchronous counter (19 bits)
>> driving a binary comparator driving a latch. To get this speed, I'd
>> probably have to throw it onto an FPGA. Does anyone have any other ideas
>> or comments? Does a single chip frame buffer exist that would capture this
>> and let me look at particular pixels using spi? Other ideas?
>
>At only 27MHz and 10 bits of data a CPLD is a viable solution.
>
>I've used the 9536 CPLD with good success, my logan project uses it (and
>connects it to a PIC):
>http://repatch.dyndns.org:8383/pic_stuff/logan
>
>TTYL

If you want a single pixel, and don't need single-pixel resolution, run the PIC synchronously with
the data stream, generate an interrupt on sync, which runs a timer which generates a second
interrupt at the time of pixel you want.
Failing that, a CPLD should be more than adequate.

2006\05\12@164354 by Harold Hallikainen

face picon face
THANKS! I'll investigate these two solutions further.

Harold

{Quote hidden}

> -

2006\05\15@092145 by alan smith

picon face
If you can capture and store to SDRAM, you can stream it out of the serial buffer as well.


               
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone  calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice.

2006\05\15@213655 by Robert Ammerman

picon face
Assuming the 27M words/second data has a clock associated with it, and a
sync signal to indicate the start of the frame you could:

1: Use the original 27 MHz signal to drive a divide by 4 circuit to create a
frequency below 10MHz.
2: Use that signal as the clock signal for a PIC18 with a 4X PLL
-- this will leave you with four pixels per instruction time on the PIC18 --
3: When the 'sync' signal occurs store the current state of the divide-by-4
and interrupt the PIC.
4: Use 2 PIC outputs to indicate which 'phase' of the 27MHz signal you want
to capture based on the phase of the sync signal relative to the PIC clock.
5: With careful timing include the two instructions BSF LATx,?  BCF LATx,?
to generate a one cycle signal.
6: External hardware uses that signal, conditioned by the two phase outputs
matched against the divide-by-four logic to latch the desired pixel.
7: Read the pixel.
8: Rinse and repeat


Bob Ammerman
RAm Systems

{Original Message removed}

2006\05\15@231623 by Harold Hallikainen

face picon face
Interesting! We're currently looking at the suggested PLD solution. I'll
keep this in mind, though!

THANKS!

Harold


{Quote hidden}

> {Original Message removed}

2006\05\16@040949 by Alan B. Pearce

face picon face
>Interesting! We're currently looking at the suggested
>PLD solution. I'll keep this in mind, though!
>
>THANKS!
>
>Harold
>
>
>> Assuming the 27M words/second data has a clock associated with it, and a
>> sync signal to indicate the start of the frame you could:
>>
>> 1: Use the original 27 MHz signal to drive a divide by 4 circuit to
create
>> a
>> frequency below 10MHz.
>> 2: Use that signal as the clock signal for a PIC18 with a 4X PLL
>> -- this will leave you with four pixels per instruction time on the PIC18

Of course, if you used a dsPic instead, you can get the 27/4 multiplied up
to something near 120MHz internally, giving even more processing per pixel.
One could probably get away with 27/3 as the input to the micro. It is
possible to make a /3 with symmetrical output using JK flip-flops.

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...