• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 268 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.

C6474 Timer Interrupt

Estian Malan
Intellectual 635 points

Hi.

 

I have been running a continuous timer interrupt using the timer module of the C6474 in GPT and continuous mode. I am attempting to see what the fastest timer interrupt is that can be sustained on the C6474 when clocked at 1000 MHz.

loading the low period timer with the lowest possible value (i.e. a value of 1), results in a continuous interrupt every 280 ns, calculating to at a rate of (only...) about 3.5 MHz.

 

Is this limitation because the Timer is situated behind the SCR?

What can I do to make it go faster?

 

Estian.

  • 0
    TI__Mastermind 18146 points

    Hi Estain,

     

    the general purpose timers are clocked with CPU/6 so in theory you could trigger an interrupt every 6ns. Bit I don't think that makes an awfull lot of sense since it will take a while until the DSP will react to the interrupt jump to your interrupt subroutine and process it then return and be ready for the next interrupt.

    How the interrupt latency in your application can be determined is another topic. Maybe see http://processors.wiki.ti.com/index.php/Interrupt_Latency_Checker

    Having a high load of interrupts is typically not prefferable so I'drather think about how to reduce the number interrupts per second.

    Kind regards,

    one and zero

  • 0 in reply to one and zero
    Intellectual 635 points

    Hi.

    I was actually measuring it all wrong.

    Using a 500 MHz Logic Analyzer I was trying to measure a GPIO pin toggled high on entry and low on exit of the ISR. This does not take into account the time it takes to enter and exit the ISR. So, this will not show you the true time between interrupts.

    So, here is how I changed it:

    Using the same Logic Analyser, I am now measuring the TMR0 output, configured in Pulse Mode with high time of 2x clock cycles. Simultaneously I am still toggling (and measuring) the GPIO pin on entry and exit of the ISR, and here are some very interesting results:

    • Due to the limitation of the measuring equipment, I am able to go as low as a value of 2 for the period low register value, which results in a verified time between interrupts of about 17.5 ns. However, this is still way too fast to verify the toggling time of the GPIO pin
    • I had to Increase the timer period low register to a value of 0x20 (decimal 32) before I could verify a stable GPIO toggle between interrupts. From here I could see that it takes a whopping 171.5 ns from when the timer interrupt occurs, until the GPIO pin is toggled high (i.e entry of the ISR)!
    • Toggling the GPIO pin back to low 'immediately' (as far as the code is concerned) takes another 18 ns (pretty quick actually), at which point the ISR is exited. Then it takes another 10 ns until the next interrupt occurs.

    Its a little difficult to verify exactly how long it takes to exit the ISR and return to the main routine, but If i was to assume that it takes 0 time (which I am sure is not the case) I would have only 10 ns (i.e. 10 clock cycles) worth of time between GPIO high and low toggles to do processing with, and be finished by the next interrupt. Not much to do anything with really... unless its a highly pipelined and optimized routine...

    However, if I was to remove the toggling of the GPIO pin from the ISR, I would gain another 18 ns (i.e. 18x clock cycles) to do processing with, leaving me with 28 ns (maybe less because of my assumption mentioned earlier) of processing time before the next interrupt. Again, this is not much time to do anything that is not highly optimized and pipelined..

    Anyway, I thought I'd share this result here, so as to hopefully shed some light for someone else out there..

    Regards.

    Estian.