2008-11-15 09:13:40     EPPI trouble on BF548

Document created by Aaronwu Employee on Aug 26, 2013
Version 1Show Document
  • View in full screen mode

2008-11-15 09:13:40     EPPI trouble on BF548

Martin Strubel (SWITZERLAND)

Message: 65339   

 

Hello,

 

I've been trying to get images from an Omnivision sensor into a BF548 (EZKIT), with no real success. I'm running the EPPI in 2 sync general purpose video receive mode.

 

What I am suspecting is, that the EPPI is no longer edge triggered to FS1/FS (HSYNC/VSYNC) signals like the PPI was. The sensitivity and behaviour of the sync signals is not very well documented in the HRM, but from experimentation, it seems that the EPPI wants at least the VSYNC (FS2) signal asserted over the entire frame duration, otherwise it will either not read a frame (if it receives no HSYNC within the VSYNC pulse) or report tracking overflow errors. The workaround is luckily, to invert the FS2, as with this sensor, the lines follow after deassertion of the VSYNC pulse. However, I still keep getting Horizontal Tracking overflows for unknown reason (I made sure that FS3 is not gating the clock).

 

Has anyone by any chance gotten this to work? I was already desparate enough to send a mail to processor.support at analog dot com, so if they respond, I'll copy cat.

 

Cheers,

 

- Martin

 

 

QuoteReplyEditDelete

 

 

2008-11-15 15:34:43     Re: EPPI trouble on BF548

Michael Hennerich (GERMANY)

Message: 65345   

 

Martin,

 

I think I checked recently some EPPI hacks for an ST VS66xx sensor into our blackfin_cam driver on svn trunk, also using 2 ext. FS mode.

 

For me it worked pretty well - you might want to sneak a peek there.

 

Let me know how it goes.

-Michael

 

QuoteReplyEditDelete

 

 

2008-11-16 09:26:46     Re: EPPI trouble on BF548

Martin Strubel (SWITZERLAND)

Message: 65347   

 

Hi Michael,

 

I've checked the data sheet of the ST sensors - they obviously deliver a VSYNC/HSYNC that would work with the EPPI, as they are asserted over the entire frame/line duration.

 

However, the Omnivision has a different syncing. No prob with the 'classic' PPI, because it would just start acquiring data on the first trigger condition from VSYNC and HSYNC in 2/3 sync mode.

 

The classic PPI ignored too many clocked in bytes per line (or lines per frame) , in general, you wouldn't see it when the sync signal was not re-asserted within the counter period. The EPPI, obviously, seems to detect over- as well as underruns, which would make sense, if the SYNC event is now level sensitive instead of edge triggered.

 

Did you ever try to modify one of the bHSyncFalling (or -Rising) registers to change the length of the hsync pulse? If it was edge triggered, it shouldn't report Horizontal Tracking over/underflows..

 

BTW, I have 0.1 silicon. Not sure whether there is newer.

 

Greetings,

 

- Martin

 

 

QuoteReplyEditDelete

 

 

2008-11-16 13:32:49     Re: EPPI trouble on BF548

Martin Strubel (SWITZERLAND)

Message: 65349   

 

To followup, I've tested the setup on EPPI1 (above experiment was EPPI0) with a video generator that I used to torture PPI drivers with. See attached picture for timing details (I've set a frame 8x8 for the image, the real frame here is somewhat bigger).

 

In this case, no frame errors occur, but I see (number of lines) Frame tracking errors. I've run automatedly through a number of PPI_COUNTs (I am aware that the EPPI wants x, not (x-1) like the PPI). I am ALWAYS getting Horizontal overflows, they simply don't go away. When x > (pixels per line plus H-Pause), I get the expected Underflow, then the EPPI of course resyncs improperly, and I eventually get like a large number of underflows and a few overflows.

 

Is there some obscure setting to do with memory, core or something like that that may cause this effect? Up to now, bad bandwith settings etc. used to result in a FIFO error on the BF537 and alike. I am still thinking that PPI_STATUS errors are directly caused by the PPI input.

 

Cheers,

 

- Martin

 

 

 

video-start.png

video.png

QuoteReplyEditDelete

 

 

2008-11-17 16:10:22     Re: EPPI trouble on BF548

Michael Hennerich (GERMANY)

Message: 65392   

 

Martin,

 

I guess you are aware of the enhanced POLC, POLS bits.

What is the PPI CLK you are driving things?

 

You are absolutely right the EPPI detects over as well as underflow errors.

It’s now critical that the EPPI setup meets 100% the incoming data framing.

 

I’m currently not on the edge of EPPI related inquiries.

I would send an email to processor.support@analog.com

 

Best regards,

Michael

 

QuoteReplyEditDelete

 

 

2008-11-18 12:58:23     Re: EPPI trouble on BF548

Martin Strubel (SWITZERLAND)

Message: 65449   

 

Hi Michael,

 

PPI_CLK ranges from 6 to 25 Mhz, depending on the clock divider used on the Video Generator. The Omnivision Chip delivers 24 Mhz, I've also tried a Micron with 6 Mhz. Shouldn't be a problem.

 

I've set the POLS such that the VSYNC would be acknowledged 'high' over the entire line clocking sequence. That bit worked - the vertical detection is working fine. Since you confirmed it detects under as well as overruns, it would mean, that the sync signals are rather 'Data valid' signals - thus need to be asserted over the entire data clocking sequence. However, the HRM wouldn't tell you this.

 

I'm still going to bug processor.support some more, the answer was so far that the AV-Extender (which I had used in one case) was not supported.

 

 

QuoteReplyEditDelete

 

 

2011-04-06 04:34:27     Re: EPPI trouble on BF548

Marius Kotsbak (NORWAY)

Message: 99621   

 

How did this problem end? Has anyone successfully used EPPI capturing an image using uCLinux at all?

QuoteReplyEditDelete

 

 

2011-04-08 08:30:26     Re: EPPI trouble on BF548

Martin Strubel (SWITZERLAND)

Message: 99696   

 

Hi Marius,

 

yes, EPPI works, I just didn't get the chance to test multi PPI functionality. Also, all EPPI framing errors will have to be ignored for sensors which can't be configured for a exactly defined timing. If you do need a proper frame loss detection for industrial applications, you have to make sure that the sensor is delivering a deterministic timing (and it needs to match the EPPI settings). Otherwise I'd rather recommend the classical PPI.

 

Greetings,

 

- Martin

Attachments

Outcomes