Post by thread:[EE] pixel capturing

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!

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

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.

THANKS! I'll investigate these two solutions further. Harold {Quote hidden}> 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. > > -

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}

Interesting! We're currently looking at the suggested PLD solution. I'll keep this in mind, though! THANKS! Harold {Quote hidden}> 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}

>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.