0

Making sense of Composite Video Timing
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Making sense of Composite Video Timing

by blipton on Wed Jan 10, 2018 9:19 pm

Looking at the Adafruit_CompositeVideo Library, I can't seem to make sense of how the timing works..

According to initialization, the DMA transfers seems to be triggered upon the completion of the previous DMA transfer:
Code: Select all | TOGGLE FULL SIZE
  dma.setTrigger(TC5_DMAC_ID_OVF);   
  dma.setAction(DMA_TRIGGER_ACTON_BEAT);


Which looks consistent with the descriptors, that each seem to point to a single line and have a transfer length of a row (50 pixels)
Code: Select all | TOGGLE FULL SIZE
desc->DESCADDR.reg        = (uint32_t)&descriptor[i + 1];
desc->SRCADDR.reg         = (uint32_t)&frameBuffer[row * videoSpec[mode].rowPixelClocks];
desc->BTCNT.reg           = videoSpec[mode].rowPixelClocks;


The part that I'm trying to wrap my head around is the Timer.
Code: Select all | TOGGLE FULL SIZE
  GCLK->CLKCTRL.reg = (uint16_t)(GCLK_CLKCTRL_CLKEN |
    GCLK_CLKCTRL_GEN_GCLK0 | GCLK_CLKCTRL_ID(GCM_TC4_TC5));
  TC5->COUNT16.CC[0].reg = videoSpec[mode].timerPeriod;
 


The timer above is set to the number of CPU ticks per pixel clock (60 ticks/pixel * 1sec/48Mhz = ~1.27us per pixel). But Why? What event happens at this rate? I don't even see if/where the timer interrupt is handled.

If anything, I would have expected this Timer to be set for the line period (60 ticks/pixel * 50 pixels/line * 1sec/48Mhz= 62.5us), and for the DMA to trigger each transfer off that interval.

What am I missing?

blipton
 
Posts: 7
Joined: Mon Nov 29, 2010 7:22 pm

Re: Making sense of Composite Video Timing

by pburgess on Thu Jan 11, 2018 3:30 am

DMA action is one beat, so one 16-bit hword will be moved from either RAM or the vsync tables to the DAC:
Code: Select all | TOGGLE FULL SIZE
  dma.setAction(DMA_TRIGGER_ACTON_BEAT);


Beat is triggered by the timer overflow:
Code: Select all | TOGGLE FULL SIZE
  dma.setTrigger(TC5_DMAC_ID_OVF);

No need for an overflow interrupt; the overflow condition itself triggers the DMA beat transfer.

There's 50 beats per line; no need for a per-line trigger/timer because it's just an implicit sum of these 50 beats. Most lines are separate descriptors as it's easier to share the same RAM for video data over multiple scanlines this way, then a couple of big descriptors for all of the vsync lines in total.

pburgess
 
Posts: 3973
Joined: Sun Oct 26, 2008 2:29 am

Re: Making sense of Composite Video Timing

by blipton on Thu Jan 11, 2018 4:25 pm

Ahh that makes perfect sense, and given the DAC supports 1M/s I see now where the ~1u pixel period update limits it to 50 pixels across (63.5us per line) ... and a 2M/s DAC would allow for twice the horizontal resolution

In terms of vertical resolution, since memory is allocated for 436 descriptors is there a reason why the vertical resolution was set to 24 (where each line duplicated 9 times)?

Code: Select all | TOGGLE FULL SIZE
    } else if(i <= 216) {
      // Descriptors 1-216 are pixel data
      uint8_t row = (i - 1) / 9;
      desc->SRCADDR.reg         = (uint32_t)&frameBuffer[row * videoSpec[mode].rowPixelClocks];
      desc->BTCNT.reg           = videoSpec[mode].rowPixelClocks;


Was that just to reduce the memory footprint of frameBuffer by allocating 23 rows instead of 436?


Sorry, last question, I promise! Regarding the initialization of descriptor 217 and 435, what is hacky about it?
Code: Select all | TOGGLE FULL SIZE
      // Descriptor 217 is vsync hack (will go away later)
      desc->BTCTRL.bit.BEATSIZE = DMA_BEAT_SIZE_BYTE;
      desc->BTCTRL.bit.SRCINC   = false;
      desc->SRCADDR.reg         = (uint32_t)&vBlank1;
      desc->BTCNT.reg           = 1;
      desc->DSTADDR.reg         = (uint32_t)&vBlank;


Is this just a way (via vBlank) to keep track of what field is currently active? Is it going away because vBlank isn't currently used in any function?

blipton
 
Posts: 7
Joined: Mon Nov 29, 2010 7:22 pm

Re: Making sense of Composite Video Timing

by pburgess on Thu Jan 11, 2018 4:59 pm

Yep, I was aiming to keep the pixels fairly square-ish. Could go for more vertical resolution but I think it'd confuse people when using the print functions and text comes out all warped.

I don't recall exactly what the vsync hack was trying to address. Even/odd fields maybe? I'd have to get pretty deep back into that code's headspace to remember where I left off, and unfortunately at this moment I'm going to a convention for the weekend. But I think it's so animation always updates on the same field number, or lets you choose one or the other, or something.

pburgess
 
Posts: 3973
Joined: Sun Oct 26, 2008 2:29 am

Please be positive and constructive with your questions and comments.