AnsweredAssumed Answered

EPPI ITU-656 transmit setup

Question asked by RichardJ on Jun 21, 2011
Latest reply on Aug 4, 2011 by Prashant

Apologies in advance for the length of this post, I find PPI set-up rather laborious!

I'm trying to configure the BF547 EPPI1 for 1080p25 output. Having read and re-read the EPPI chapter, calculated the various settings and tried them, I'm finding slight discrepancies. I have EPPI_CLK = 66.6666MHz (15ns), and would like:

 

16-bit "pixels" using packed DMA transfers from a framestore of 1920x2x1080 bytes.

Embedded EAV, SAV and blanking in the EPPI output stream (BLANKGEN set).

HSYNC and VSYNC outputs on port pins (to help me scope the board).

Total frame length = 1334 lines periods

Total line length = 1999 EPPI_CLK periods   (yields 1334 * 1999 * 15ns = 40ms)

1920 "active" pixels per line, hence blanking of 79 clock periods.

1080 "active lines" per frame, thus blanking of 254 line periods.

 

#define screen_clocks_per_line  1920 // length of on-screen line

#define Hblank                           79   // total non-active pixels per line

#define screen_line_count          1080 // number of on-screen lines

#define Vblank                           254 // total lines of blanking per frame

#define savlen                            4 // length of SAV and EAV codes in EPPI clocks
#define eavlen                            4

 

// with reference to ADSP-BF54x Blackfin Processor Hardware Reference p 15-24, though text bias is towards RX mode

*pEPPI1_FRAME   = screen_line_count + Vblank;       // FS1 assettions between frame syncs
*pEPPI1_VCOUNT  = screen_line_count;                    // number of lines to xmit / recv.
*pEPPI1_LINE  = screen_clocks_per_line + Hblank;     // number of clocks between FS1 assertions
*pEPPI1_HCOUNT  = screen_clocks_per_line;             // number of samples per line
*pEPPI1_VDELAY  = 0;                                             // top justified (actually we'll fill, no black band)
*pEPPI1_HDELAY  = 0;                                             // left justify

 

// with reference to ADSP-BF54x Blackfin Processor Hardware Reference page 15-19:

*pEPPI1_FS1W_HBL    = Hblank-eavlen-savlen;          // agrees with p15-93, my Hblank is all non-active pixels (inc EAV/SAV)

*pEPPI1_FS1P_AVPL   = screen_clocks_per_line;     // number of active samples per line, agrees with p15-93

 

// with reference to ADSP-BF54x Blackfin Processor Hardware Reference page 15-93:
*pEPPI1_FS2W_LVB    = Vblank;                              // number of lines of vert. blanking
*pEPPI1_FS2P_LAVF   = screen_line_count;              //p15-95, number of active lines per field

*pEPPI1_CONTROL = 0x68121FA3;

 

When this didn't quite get me the timing I needed I created a smaller frame to investigate using a scope.

Aiming for 100 clocks wide by 100 lines long, (60 "active", 40 blank) pixels * (70 active, 30 blank) lines:

 

#define screen_clocks_per_line  60   // length of active on-screen line

#define Hblank                          40   // non-active pixels

#define screen_line_count         70    // number of on-screen lines

#define Vblank                          30   // blanked lines

 

When running

HSYNC period is 1.5us so 100 pixels as desired, split 540ns/960ns so 36 (blank) / 64 (active) pixels.

VSYNC period is 106.5us which is 71 lines split 31 (blank) / 40 (active).

So out in both cases. It looks as if either SAV or EAV is being counted not as blank but as active pixel data, and what happened to the active lines?

 

I've not found a way of indicating I want to output progressive video, isn't there a chance the F bit will be toggling? _CONTROL[7] is for Rx only

 

Any clues anyone?

Outcomes