• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 358 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Maximum cycles to safely disable interrupts for video applications?

RobbySun
Expert 1120 points


Hi,

I have a video application running on the DM6437 EVM. The video frames (VGA resolution) are input via VPFE; my application processes them, and sends the output to VPBE to be displayed. The application is very computation intensive, and I want to disable interrupts as long as possible so that my application runs faster. 

I tried the compiler option 'mi' (interrupt_threshold) of 1; the application is quite stable, albeit a bit slow. Setting 'mi' to 256 causes the application to abort. My guess is that the video driver runs into trouble with interrupts disabled for so long. The video input/output framework is based on TI's video_preview example.

Now my questions are: 

1) What's the maximum number for 'mi' in order to keep the video driver running?

2) What else may break if interrupts are disabled for 256 cycles?

Thanks,

 

  • 0
    TI__Mastermind 41665 points

    RobbySun said:
    1) What's the maximum number for 'mi' in order to keep the video driver running?

    The video driver only needs to interrupt very rarely relative to the system clock, as it only needs an interrupt once a frame for completion, and that only has to happen fast enough so that the port can be reconfigured for the next frame, guaranteeing 256 cycles max of interrupt latency should be much more than enough.

    RobbySun said:
    2) What else may break if interrupts are disabled for 256 cycles?

    This depends on what else you have in your system, to find out what is breaking you would need to look further into how your application is failing, I am not sure what you mean by 'abort'. Given you are using video_preview the only active drivers should be video and i2c related. I suspect something else is going wrong here though, since I was able to run the default video_preview example with -mi 256 without any problems which makes this sound like it might be a compiler problem, you may want to try upgrading your code generation tools (CGT) to the latest version through update advisor.

  • 0 in reply to Bernie Thompson TI
    Expert 1120 points

    Bernie Thompson said:

    This depends on what else you have in your system, to find out what is breaking you would need to look further into how your application is failing, I am not sure what you mean by 'abort'. Given you are using video_preview the only active drivers should be video and i2c related. I suspect something else is going wrong here though, since I was able to run the default video_preview example with -mi 256 without any problems which makes this sound like it might be a compiler problem, you may want to try upgrading your code generation tools (CGT) to the latest version through update advisor.

    Thanks Bernie for your timely feedback. 

    Other than my application and the video preview framework, there is nothing else in my system. When my application aborts, it always falls into a UTL_halt() call. I'm using CCS 3.3.82.13, CGT 6.1.10, and DSP/BIOS 5.31.07, but I use CCS DSK (3.3.38.2) to load/run the code onto the EVM board.