(((This *IS* a Linux software question, relating to the VPIF software.)))
STRAIGHT TO THE QUESTION:
My ARM is busy, I've tried to make it yield enough, but I still get blinks on my output video monitor, presumably due to messed up 30/sec frame timing.
The code I got when I inherited this project uses a local modified copy of VpifDisplay.cpp (not sure where this source comes from). Within that, I see getDisplayBuffer() and putDisplayBuffer() calling ioctl() to dequeue and queue buffers, respectively. Down at the ioctl() level, it shouldn't matter if I'm late providing a buffer or anything like that. So why does my monitor output blink? Is the keeping of the queue of buffers maintained solely in hardware (in which case processor business means nothing), or is there active code down below that ioctl(), such that when the ARM gets too busy, it will fail to feed the VPIF hardware in a timely manner.
BACKGROUND SO IT MAKES SENSE:
On two prior products, my NTSC or VGA output from a DaVinci DM6467T chip was nice and clean, regardless of how busy my application software was.
Now, on a new OMAP L138 product, where someone else wrote the baseline software, my NTSC output is blinky. I'm trying to figure out why.
By blinky, I mean that periodically the image on my monitor jumps. I haven't looked yet with a scope, but I'm confident the reason is that the regular 30/sec timing of frames is irregular sometimes, causing the monitor to blink.
I've tried putting yield statements in all the loops in the other threads in my software, but this has only helped a little. I could continue down this yield path as well as a priorities path, but I come to a particular question.
On my prior products, doc for the example I started with said that the VPIF will repeat the last frame if I don't provide a new one in time. Therefore, if my application was busy and slow, the output just reproduced the prior frame with NO timing anomalies to cause the monitor to blink.
On this product, an inherited bug (from the ringio example, they fail to ever zero totalRcvbytes) caused me to eventually cease sending frames to VPIF at all. The output would freeze. This is CONSISTENT with my understanding of the prior products. So, WHY do I get the blinky problem when I *do* send frames, albeit potentially early or late, or with other processes or threads taking up too much processor time?
