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
