Hi @DrKarthi
I think that the delay you are noticing is caused by the functions executed between the time the PWM signal is generated and the time when the action inside the PWM Callback function is executed (in your model's case the DIO channel toggle). Please note that the code generated by the MBDT blocks is based on the RTD (Real Time Drivers). The PWM Callback function is called from the implementation of the RTD for the EMIOS Interrupt Service Routine, where several actions are performed, additional to the call to the user callback. The time in which these actions are executed is reflected in the delay between the edges of the two signals (PWM and DIO). Moreover, the Dio_WriteChannel function, contains additional functions as well, called in a specific order, until the point where the actual value of the signal is changed (from 0 to 1 or vice versa).
One way in which you could improve this time, is to change the optimization level for the compiler settings, inside the Code Generation tab of the model's Configuration Parameters. I have tested the same model with the -O0 optimization level (as your model is set), and with -O2 (increased level of code optimization), and in the results obtain I am noticing an improvement of this delay time. Please see the attached images.
The first one corresponds to the initial settings for the compiler optimization (-O0), and the second one corresponds to the -O2 flag, available by selecting the Faster Runs Build Configuration.
Please let us know if this helps,
Irina
Hello @DrKarthi,
For enabling the execution of a callback associated to a Pwm channel at both edges of the PWM signal, besides setting the Notification on PWM_BOTH_EDGES using the Pwm_EnableNotification, like you do in the Initialization subsystem of your model, one additional setting is needed in the associated .mex configuration file.
Hence, can you please set the Flag Generation parameter on the Both_Trailing_and_Leading_Edge option and check if after this change you can achieve the desired behavior? I have attached below a screenshot of the setting.
I have tested your model with this setting, with a minor modification that inside the PwmChannel_0_Callback I am toggling the RGBLED0_BLUE LED, instead of constantly feeding it the 1 value. After connecting a Logic Analyzer to the pin on which the PWM signal is generated (PTA1) and also on the pin corresponding to the LED (PTA31), I have obtained the following results.
As you can see, at each edge of the PWM signal, the LED is changing its value, meaning that the callback its executed at both rising and falling edge.
Moreover, for making sure that the Simulink generated code gets updated according to the latest modifications inside your model, between consecutive build of your application, you could try erasing the modelName_ert_rtw, slprj folders and also the modelName.slxc file.
Please let us know if this helps or if further information is required from our side.
Thank you,
Irina
Thanks for your detailed explanation. We tried your suggestion, and it works for both the rising and falling edges.
However, we are encountering an issue with the flag generation for '0' & '1' during edge triggers.
Conditions:
We are controlling the first PWM-1 generation using a software/hardware interrupt. Based on PWM1, the PWM2 callback (PWMchannel_0_callback) functions correctly for both the rising and falling edges (0 & 1).
Challenges:
With each software/hardware interrupt, the flag generation condition seems to vary in response, switching from 0 to 1 and 1 to 0. Due to this, the on and off times of the PWM signal change unexpectedly.
During the first interrupt (Ign_status = 0 to 1), the edge flag is 1 for a short time and 0 for a long time.
During the next interrupt (Ign_status = 0 to 1), the edge flag is 0 for a short time and 1 for a long time.
I’ve attached the model for your reference. Kindly help as soon as possible.
.png){kind=link}
