• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 352 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.

LAUNCHXL-F2800157: Best way to space timers so interrupts don't all fire at the same time

Michael Bagherpour
Prodigy 30 points
Part Number: LAUNCHXL-F2800157


I'm setting up 3 timers, each of which will trigger a hardware interrupt. However, I don't want these interrupts to trigger while one of the others is being handled by its ISR. The work done in most of the ISRs is very predictable -- I know how much time is spent in each ISR to a decent precision. My idea is to set the timers intentionally so the interrupts fire at different times, leaving space for the ISRs to complete. I have some ideas, but am unsure of the best way to achieve this.

Here's an overview of the interrupts, timers, and ISRs:

1. RTOS tick interrupt -- driven by CPUTIMER2, fires at 1 kHz. I don't know exactly how long this ISR takes, but it's less than 15 us.

2. interrupt for 10 kHz loop -- driven by EPWM1, fires at 10 kHz. This ISR takes 13 us.

3. interrupt for 1 kHz loop -- driven by EPWM2, fires at 1 kHz. This ISR takes 70 us.

This is more or less how I'd like the interrupts to fire:

My progress so far:

 - I noticed that the EPWM module has function EPWM_setTimeBaseCounter, which allows me to align / offset the EPWM timers as much as I'd like, by setting the value that these clocks start at. This has been straightforward.

 - However, the CPUTIMER doesn't seem to have an equivalent function. I did find CPUTimer_getTimerCount, and I can imagine offsetting both EPWM's relative to this, but it just seems like there should be an easier way

Explicit Questions:

1. Is there a "standard" way of offsetting these interrupts? If so, what is it?

2. Is my approach of using EPWM_setTimeBaseCounter and CPUTimer_getTimerCount reasonable? Is there any easy way to work out the math, instead of doing it (and making mistakes) myself?

3. How would one go about spacing the interrupts if they had only used the CPUTIMERS (CPUTIMER0/1/2). Naively, it kindof seems like I got lucky by setting up my non-RTOS loops with the EPWM module, which has the EPWM_setTimeBaseCounter function available.

4. Anything else that I'm missing or that seems very weird about this?

  • 0
    TI__Mastermind 30185 points

    Hello Michael,

    Michael Bagherpour said:
    1. Is there a "standard" way of offsetting these interrupts? If so, what is it?

    No, to my knowledge there is no standard feature that enables this sort of offsetting.

    Michael Bagherpour said:

    2. Is my approach of using EPWM_setTimeBaseCounter and CPUTimer_getTimerCount reasonable? Is there any easy way to work out the math, instead of doing it (and making mistakes) myself?

    3. How would one go about spacing the interrupts if they had only used the CPUTIMERS (CPUTIMER0/1/2). Naively, it kindof seems like I got lucky by setting up my non-RTOS loops with the EPWM module, which has the EPWM_setTimeBaseCounter function available.

    4. Anything else that I'm missing or that seems very weird about this?

    These are more generic application-based questions, I'll do my best to answer them but it's better to ask this on a general engineering forum. E2E is meant to support questions about TI devices/EVMs/software, application-specific questions are not usually addressed unless they are part of some reference design we provide.

    From my perspective, the best way to make sure that no other interrupts get triggered while a CPU timer interrupt is being handled is to either stop the counters or disable global interrupts and then re-enable them at the end of the interrupt. While this is more brute force, it's more reliable than trying to math out an approximate timing which may be unreliable (as any deviation in code execution will mean reconfiguring the entire interrupt timing). If the requirement is simply to not have interrupts trigger at the same time, pausing the counter or disabling interrupts would be the way to do this. There may be other ways that I haven't thought of.

  • 0
    Prodigy 30 points

    For posterity, I spent a good amount of time on this strategy of spacing interrupts apart to intentionally avoid interrupts firing at the same time. I eventually got it to kindof work with the strategy I described in the original post, but it wasn't very straightforward. It doesn't seem like there are many people that try to do this. I think people don't do this because there are generally other interrupts that will throw a wrench in things anyways -- very rarely are all your interrupts driven by a clock which you can carefully space. For instance, you probably have interrupts due to communication, various sensors (encoder, etc), which will fire at times that are not known a-priori. You can't avoid having your timer-based-interrupts collide with these, so instead of spacing your interrupts to minimize collisions you probably just design your software to work well enough _even with interrupts colliding_.

  • 0 in reply to Michael Bagherpour
    TI__Mastermind 30185 points

    Hello Michael,

    Michael Bagherpour said:
    I think people don't do this because there are generally other interrupts that will throw a wrench in things anyways -- very rarely are all your interrupts driven by a clock which you can carefully space.

    Yes, this is crucial in real-time control especially when interrupts can come at any moment and are required to be handled immediately/fast. Let me know if you have further questions