Vsync and interrupt relationship (dm6437)

Erman,

The width of the VSYNC pulse is programmable; hence you can control (VSPLS register) and hence you can program it to be the lenght of th vertical blanking interval or perhaps something smaller (or bigger but you will loose some valid video data).  This is detailed in the VPBE UG.

Let us know if the helps and if there is anything else we can assist with. 

I believe the statement that the VPBE generates an interrupt at the end of every frame event is potentially misleading as you have shown here, my understanding is that the interrupt that is the end of the frame and the interrupt that is the VSYNC are one and the same. Because you have a continuous stream of frames, that which is the end of one frame is the beginning of another, where the VSYNC edge is in the blanking space between them is defined by your video standard, thus where the interrupt happens may vary by your standard, as Juan mentioned you can adjust where the VSYNC edge happens assuming you are in master mode.

Based on this I agree that what you operate on in this interrupt function may not be latched for this new frame that is starting with the interrupt, as many of the registers in the VPSS only latch and take effect upon a VSYNC edge.

Thank you for responding.

But I can't understand the purpose (or logic) of manipulating the vsync width. I think I am having a concept confusion.

Please correct me If am I wrong:

-VSYNC is a signal that is generated at the end of every frame. It's purpose is, as far as I understand, to indicate the current frame is ended and a new frame is about the begin.

-Between the end of a frame and the beginning of the next one (or between the valid image data), there is a vertical blankin time.

-During this blanking time, I think the output is still the previously processed frame. I am curious about this, what output I take during the blanking time, when there is no valid data.

-Latching means locking the related register bits. These register bits are released when VSYNC edge happens. (High edge, low edge? The release is likely to happen in the start of the VSYNC pulse, hence it is likely to be high edge?)

-Whatever I modify in registers during this blanking time is a safe operation. Meaning, for example if my interrupt execution is not flowed to the valid data time and executed in the blanking time, I can't do any harm to output, like loosing valid data.

From this information, I can't answer what the width of vsync (VSPLS) is and why I should want to change it. Maybe it is used to know when to latch bits and to not, with the end of a vsync pulse, register bits may be latched?

Also this is another rookie question but I would like to learn if there is a way to calculate VSYNC interval?

Thanks again.

Elric said:

-VSYNC is a signal that is generated at the end of every frame. It's purpose is, as far as I understand, to indicate the current frame is ended and a new frame is about the begin.

VSYNC or Vertical Synchronization, is a signal that is used to signify when the receiver of a video stream should be prepared for a new frame, you could think of this as something that happens at the end of a frame or at the beginning of a frame, either way it is an event that happens some time between frames (I think technically it would be the beginning of the frame such that you could have a single frame capture). Depending on your video format this can take the form of a seperate line that has an edge on it between frames or as a special code within the datastream in the case of BT.656.

Elric said:

-Between the end of a frame and the beginning of the next one (or between the valid image data), there is a vertical blankin time.

This is true, the width of this blanking period varies by video standard.

Elric said:

-During this blanking time, I think the output is still the previously processed frame. I am curious about this, what output I take during the blanking time, when there is no valid data.

Both the capture and display sides will have blanking periods, if the pixel rates vary than the processor will either drop frames or repeat frames so that the display can match the source. I am not sure I entirely understand the question, but I would say that since video is so fast (for the human eye) that the blanking time is simply wasted bandwidth, so your code can be doing any processing on the video in between blanking just as it can while the next frame is being captured. Originally blanking was in there to meet the physical timing requirements of displays, CRTs needed a certain amount of time to prepare for each new line and new frame, these days in a digital sense the blanking data only helps to keep a constant pixel clock frequency with varying resolutions and frame rates, but effectively is wasting the bandwidth (though since it is not necessary it may not be considered truly wasted).

Elric said:

-Latching means locking the related register bits. These register bits are released when VSYNC edge happens. (High edge, low edge? The release is likely to happen in the start of the VSYNC pulse, hence it is likely to be high edge?)

Latching means that the bits are taken into effect, the edge of the physical signal can vary (you can adjust that with a register, I believe default is the rising edge). The idea behind this is that it would be bad for the VPSS state machine to change its configuration in the midst of a frame, so it uses the VSYNC signal to latch in the register values, such that any changes that would effect the capture operation do not go into effect until the frame after the VSYNC that the registers were configured before. This kind of goes in hand with the idea that the VSYNC pulse is really the signal to start a new frame as opposed to signal the end of a prior frame, in that the registers must be ready before the VSYNC to effect the frame following the VSYNC.

Elric said:

-Whatever I modify in registers during this blanking time is a safe operation. Meaning, for example if my interrupt execution is not flowed to the valid data time and executed in the blanking time, I can't do any harm to output, like loosing valid data.

Since the registers are latched on the VSYNC you are protected (i.e. changing the latched registers will do nothing if you do it in the middle of a frame capture), though if you have only some of the registers you wanted to change written to when the VSYNC hits you could end up with a configuration you do not want. This being said the best time to program the registers is probably right after a VSYNC so there is a larger amount of time before they are latched in.

Elric said:

From this information, I can't answer what the width of vsync (VSPLS) is and why I should want to change it. Maybe it is used to know when to latch bits and to not, with the end of a vsync pulse, register bits may be latched?

If you are the master on the video interface, i.e. you are generating the clock and sync signals, than you can define the width, how wide you want it depends on what the video device you are talking to requires. As the signal is meant to be edge triggered, most devices probably do not mind if the pulse width is relatively small. If you are the slave, and the external device is generating the sync signals than the VPSS has to be setup to deal with the timing, though since it is edge triggered the width does not matter much, I would say at least as wide as a clock period or two to ensure it is picked up.

Elric said:

Also this is another rookie question but I would like to learn if there is a way to calculate VSYNC interval?

The interval (time between edges) of the VSYNC signal is equivalent to the time between frames, i.e. 1/framerate, so if you have are working at 30fps than the interval would be 1/30th of a second. In other words you should have a VSYNC edge in between each frame.

Thanks Bernie. This really helps a lot.

Hi,

Just to take this a bit forward,

1. Assuming that my frame begins on a rising edge, my window addresses get latched by the VD. So no matter what the address is(I expect to have written my next frame address into the registers), the only thing the latch ensures that is the active address is only the address which is the register state at the time of VD edge; however multiple addresses I overwrite during the blanking dont affect at all. Am i correct in deducing this?

2. Then, do I need to worry about the lenght of my service routine thinking that in such a case I can actually repeat/loss frames at the display/capture interfaces?

Thanx!

Sundar

Sundar said:

1. Assuming that my frame begins on a rising edge, my window addresses get latched by the VD. So no matter what the address is(I expect to have written my next frame address into the registers), the only thing the latch ensures that is the active address is only the address which is the register state at the time of VD edge; however multiple addresses I overwrite during the blanking dont affect at all. Am i correct in deducing this?

This is correct only it is not just the blanking period, you can be writing to that address through out the entire frame and it will not take effect until the next vertical sync edge.

Sundar said:

2. Then, do I need to worry about the lenght of my service routine thinking that in such a case I can actually repeat/loss frames at the display/capture interfaces?

Theoretically if your service routine that is writing to these latched VPSS registers was so slow that it did not complete before the next vertical sync edge than you could run into a situation where the frame following such an edge would not have the proper configuration. However this situation seems unlikely, since in general the video frame rate will be many orders of magnitude slower than the processor, and service routines in particular are typically made to be extremely fast. A more common situation that would be similar to this would be if you somehow mistakenly disabled interrupts indefinitely (meaning the routine never runs), in this case your video driver would halt.

Hi Bernie,

That was fast, quick and fairly in line with what I was thinking :).

My only reason for these thoughts was to think of some optimized way to shorten my capture ISRs which till now was being thought to include some time-stamp checking, frame drop checks, and some frame ID validation. In a scenario where I would be needing to run some heavy encoder at the application side and have a risk of being already over-writing some frames, I was thinking to reduce the possibility of frame drops due to such slow performing ISRs :)

Thanx!