Have problems with setting fixed step size for TI c2000.

I constructed a simple model with a 1s pulse generator and a GPIO block for blinking an LED. I st it to stay on for 1s and off for 1s. But as i change the fixed step solver time setting (Highlighted in below image), LED blinking time is varied significantly. Why is that happening. How set the fixed step size properly. Simulink file is attached to this.

Answer 1

[Venkatesh Chilapur]

We probably have a overrun scenario due to high sample rate. Please refer this post for the implications of the overrun condition and how it affects the overall model execution.

https://in.mathworks.com/matlabcentral/answers/326670-how-can-i-get-the-code-execution-tome-of-the-model-in-simulink-for-the-code-generation-of-the-c200

You can also use sample based configuration for the PWM generator which is suited for a Fixed step solver.

Answer 2

[samith perera]

Can you tell me what is the reason for the time dilation in the code. I used a sine wave generator function with 50Hz frequency and uploaded it into the c2000 hardware. But i got only 25Hz (Half) of it from the output pin . Other time varying applications also show same behavior which is i get half/twice of what i expected. I used 0.0001s sample time for the solver configuration. thank you

[Antonin]

Dear Samith,

As explained in the link provided by Venkatesh, if a task is scheduled at 50µs and constantly takes 65µs to execute (overrun scenario), you will see this task scheduled at 100µs as we will always skip one execution every cycle. If the task takes 125µs to execute, it will run every 150µs as we will skip twice every cycle, and so on...

Your sine wave generator is executed based on a counter that updates at the base rate of the model. If you are in an overrun situation, the typical behavior is to see the sine wave frequency reduced by half for a single overrun, divided by 3 for a double overrun and so on.

Overruns are catastrophic scenarios that you should always avoid. You can use our profiling tools to measure the execution time of your models and make sure that you stay away from them.

There are practices that will make the generated code inefficient and may cause these overruns. Try to avoid float math on a processor that doesn't have an FPU, don't use saturation and rounding when not needed, don't use sample times that are not an exact multiple of a known base rate, don't pick a base rate that is too small, etc.

I hope it helps,

Thanks,

Antonin.