TMS320F2808: Difference Between Idle Task and Software Interrupt Triggered Task

Cevikalp,

I'm going to loop in the MW team, as I beleive these are there implementations in SW.  

Best,

Matthew

Hi,

The main loop works as a background task. This is the task that comes in to picture when the foreground task (that are triggered at model sample time using a timer interrupt) have completed. The Idle Task block from the support package can be used to make the required code to get executed in main loop(background task).

And software interrupt is like any other interrupt that switches the context and run the code in ISR corresponding to the interrupt. So the difference is, Idle Task runs in the end (very low priority) after all the foreground execution is complete, but SWI preempts even the foreground task execution to execute its ISR.

Hope this is clear.

Hi,

Thank you for the quick response. So as far as I understand, the code in terms of execution order is as follows:

-Software Interrupt Triggered Tasks(Call it Section 1)

model_step(){

-Main Code in its own Execution Order(Call it Section 2)

}

-Idle Task(Call it Section 3)

Then, I have to ask a second question in order to clarfiy things:

-Consider the case I have an algorithm consisting of trigonometic and mathematical functions which has high computation time and if I run it in Section 2, it really slows down the code as the entire loop can not be executed in desired cycle time. My first try was to put it in Section 1, in other words, I ran the algorithm inside a sofwtare interrupt triggered task at every 10 ms. This approach helped the entire code to run faster, in other words, in desired cycle time. Secondly, I put the same algorithm inside Section 3 and the result was desired cycle time for the entire code. 

Then, I decided to make the SWINT Task and Idle Task run the same algorithm for n times respectively(Consider n subsystems of the same algorithm). Let's say n is 6. When I did that, even though I run the same algorithm for n times under SWINT Task, the entire code slew down, the cycle time exceeded the desired cycle time. When I did the same thing under Idle Task, the entire code did not slow down, the cycle time was as desired. 

My question is:

-Can we run infinitely many functions or subsystems under Idle Task? To what extent we have freedom about it?

-How can we determine the capacity for a SWINT Task to execute several tasks which will not affect the entire code cycle time?

I hope my explanation and questions are clear.

UPDATE ON 05/06/2020:

-I noticed that under Idle Task, any function is executed way much faster than being executed in step function. What is the logic behind it?

Hi,

Here are few things to consider:

The base task is a slower lower-priority task, referred to as the infrastructure task. It depends on the model step time and we program the Timer 0 module to interrupt at periodic time intervals to run this base task. The default priority value of the base rate task is 40. The task priority indicates the relative importance tasks associated with the asynchronous interrupts. . If an interrupt triggers a higher-priority task while a lower-priority task is running, the execution of the lower-priority task is suspended while the higher-priority task is executed. The lowest value represents the highest priority. So the priority value for each asynchronously triggered task must be less than 40 for these tasks to suspend the base rate task.

So in your case, if the SW interrupt is at a higher priority(lower number < 40) then it will displace the base task from execution and run. I am not sure of the base rate in your case, but the SW interrupt that runs at 10 msec will suspend the base task and starts its execution. And if you get next base task to occur while SW interrupt is running, the base task will continue to suspend until the higher priority SW interrupt is not done. The result is, base task will skip an execution window. And that is probably the reason why the SW interrupt is able to execute all your code. But if the overall code that executes under SW interrupt is > 10 msec then we will see problems with SW interrupt also. The reason is, until the current interrupt is not completed, we will not clear the interrupt DONE flag. So a new SW interrupt coming from the same source will not be registered. Hence a window of execution for SW interrupt will be skipped.

The diagram above also holds a key idea on the impact the foreground task has on the background task. If the foreground task continue to occupy all the time before the next step time comes into picture, the background  task will not have time to execute. slot 1 and 4 show this scenario in above picture. That is the reason why your calculation in background are not executing as you keep increasing the execution load in foreground.

You can use our profiler to measure the execution time taken on the processor:

https://www.mathworks.com/help/releases/R2020a/supportpkg/texasinstrumentsc2000/ug/real-time-code-execution-profiling.html

If you have an oscilloscope, you can also set and reset GPIO pins at the beginning and the end of the different tasks to measure execution.

Hope this helps!

Hi,

Thank you for this detailed and perfect explanation! It really helped to clarify things for me. From now on, I understood the difference and execution of base task and software interrupt task based on its priority value assigned by the user and the following questions are answered:

-How can we determine the capacity for a SWINT Task to execute several tasks which will not affect the entire code cycle time?

-Can we run infinitely many functions or subsystems under Idle Task? To what extent we have freedom about it?

But the following question still remains unanswered as I would like to share few more observations:

-I noticed that under Idle Task, any function is executed way much faster than being executed in step function. What is the logic behind it?

For instance, if the base task is set to be executed at 1 milliseconds and if a counter is set at the beginning, at t=1sec, the counter is expected to be 1000. When I did the same under Idle Task, the counter goes way above 1000 at t=1. What is the reason for it?

Hi,

This explanation also answered my previous unanswered question, so thank you for your patient explanations overall.

Hi again,

As I dig deeper , I come up with new problems. My question is:

-The previous mathematical function that I mentioned is executed under Idle Task for let's say 80 times. Also, to calculate the execution time of Idle Task, I put a counter under Idle Task and let it increase. At every 1 second interval, I calculate the execution time of Idle Task from the amount of increase in counter and the outcome for this case is 60 milliseconds. At the same time, the step function(our base task) is executed without any slow down, at 1 millisecond. My question: since the Idle Task execution takes 60 milliseconds, does this mean that the step function is skipped 60 times? My guess would be after 60 milliseconds, the step function is executed and then another 60 milliseconds is used for Idle Task. To sum up, it would be something as follows:

1 millisecond step()-60 milliseconds Idle Task()-1 millisecond step()-60 milliseconds Idle Task()-1 millisecond step()-....

Cevikalp,

I think what is missing is that after the 60ms Idle Task completes, there still could be idle time left in the system/control loop.  While the base task only needs 1ms to complete; what is key here is how often it needs to be called/ran.  This has to be >>60ms, which is why the IDLE task has time to complete, and you don't see any issue with the base task not happening as it should(I assume from your last post).

I don't know your exact system, but the base task in most of our control systems is related back to the primary PWM period, that most triggers come from this time domain, and your base task will want to process a snapshot of the system at this rate(usually ADC sample) and then after applying some control law/calcs make any changes to the PWM to change the system accordingly(new duty cycle for instance).  So long as this process has ample time to complete, you will have idle time that the idle task coudl run.

I think there is some expecatation that the user determines if in general there is some idle time and if you wish for all idle tasks to complete once they are started there is that margin.  I could see a situation where the idle task gets interrupted if the system control loop needs to re-assert; this would be important since the system could be impacted if that code were held off by an idle task.  I would think this is how the code is setup from MW.

Best,
Matthew