Pwm interrupt Microchip clarification

I have configured pwm interrupt for every 30 micro sec. The clock frequency is 20mhz for microchip dspic family. I want to execute a logic at 30 micro sec hence i configured pwm and the algorithm involves lot of mathematical calculations. My problem is if i am toggling some port in the main it does not execute. But if i toggle in the pwm interrupt it toggles. What shall i conclude whether it is ok to proceed like this with checking the functionality or there is fundamentally some mistake in code not executing main. Please suggest.

My guess Is that you are stuck in your interrupt handler. You are doing so many steps in the handler that when the handler finishes another interrupt occurs.

Is it kind of ok or what shall i do since i want the calculations to be done at 30 microseconds.

electronicsman said:

Is it kind of ok or what shall i do since i want the calculations to be done at 30 microseconds.

Click to expand...

It sure SOUNDS like it's not ok. What you should do is verify how long it takes your interrupt handler too run. If it's close to 30 microseconds, you've got a problem.

Are you able to use the PWM module in the MCU you are using? You don't say which device other than it is one of the dsPIC families - I think most, if not all, have PWM hardware (not sure about all of the dsPIC30 family).
If you are trying to manipulate things every 30uSec then it would seem you are trying to do the PWM in software and that is probably not a good thing to do.
What is the underlying problem you are trying to solve - your approach may not be the best one under the circumstances.
Susan

Thank you for the reply. I am trying foc algorithm which involves transformations. In one of the reference documents asking to implement the logic in 30 micro seconds. But by toggling the port i found that the logic takes 4 ms. What shall i do? Very confused.

- - - Updated - - -

Added to that i want to say the micro is dspic33ev.

- - - Updated - - -

Sorry my mistake the algorithm is not at all running at the start of the function i enabled a port and the end i disabled the port. I see only the high of the port but low is not happening.

Well, you can't run a 4ms routine in 30 us. Your last post was very confusing. HOW LONG DOES IT TAKE YOUR ALGORITHM TO RUN?

Sorry i verified again the algorithm takes 2 ms. But i put this algorithm in the pwm interrupt which i configured for 30 micro seconds.

electronicsman said:

Sorry i verified again the algorithm takes 2 ms. But i put this algorithm in the pwm interrupt which i configured for 30 micro seconds.

Click to expand...

Well, then, you'd better rethink this. Do you actually NEED the algorithm to run every 30 microseconds? If not, then move it outside the interrupt handler. If so, then you've got a two-pounds-of-stuff-in-a-one-pound-bag problem.

- - - Updated - - -

electronicsman said:

Sorry i verified again the algorithm takes 2 ms. But i put this algorithm in the pwm interrupt which i configured for 30 micro seconds.

Click to expand...

Well, then, you'd better rethink this. Do you actually NEED the algorithm to run every 30 microseconds? If not, then move it outside the interrupt handler. If so, then you've got a two-pounds-of-stuff-in-a-one-pound-bag problem.

But thats what reference document says, not sure what to do. I am thinking of several options like increasing operating frequency. Currently it is 20mhz planning to move to higher frequencies. One clarification i require is there a post scaler for pwm will it help me?

If I understand right, you want to update the field oriented control algorithm once per PWM period. That's surely preferred to get a smooth flux waveform, but is apparently beyond the performance capabilities of your controller. Presumed the controller is already running at maximum speed, you either need to make the algorithm implementation more effective or run it at a fraction of the pwm clock.

Do you really need to update your PWM every 30uS? You don't say what you're controlling; you may not need to run that fast.

Can you show us your code? What "reference document" are you referring to - please post a link?
Also, I'm making a guess here but are you using floating point numbers in your calculation? If so then you really should look to changing to use fixed point or some other number format that the MCU can handle natively. You have a device that includes a DSP but you really need to make sure that the way you implement any algorithm is such that it uses the DSP capabilities (which are really just a MAC instruction for these devices) effectively.
Also there is a difference between needing the algorithm to run in 30uSec and running that algorithm EVERY 30uSec (or whatever the underlying PWM frequency requires). Which do you need?
Susan

Thank you all for the great replies. Here is the document i am referring to **broken link removed**. View attachment eda.zip. I have attached the source code along with the reference document. please review.

Looking at the document you refer to, there is a section on "Fixed Point Arithmetic" (page 18) that says the DSP used (a TMS320F240 - which is a 16-bit device running at 10MHz) is programmed using this number representation. They also show how to use a sign lookup table.
On the other hand, your code uses 32-bit double precision values all through it as well calls to trig functions.
You are only running your MCU with a 20MHz clock which implies 10MIPS - according to the 'include' statement (which may or may not be the correct way to do this depending on the compiler) you are using the dsPIC33EV256GM106 so you can set the clock up to 140MHz or 70MIPS.
However, even running the clock up to that speed would not overcome the overhead of the 32-bit doubles and the trig calculations.
I can't see the .h files, nor a 'main' function or the config settings so that slows things down a bit to understnad what is going on.
I can see that you are triggering the PWM interrupt every PWM cycle but in the code that is called by the PWM ISR (which includes function calls that add overheads but they will be swamped by the other issues mentioned above) I'm not sure how often the various current and voltage values (I assume that is what those variables represent) change as that would seem to depend on the signal inputs to PORTA0 and PORTB0. My guess is that these are a lot slower than the 60uSec mentioned in the referenced document as the PWM base frequency. If so then you only need to perform the calculations when those input change, not on every PWM cycle.
I'm guessing (again) that you are using the input comparative as a Quadrature Detector to know the rotor angle. As you don't seem to be using the DSP capabilities of the MCU you have chosen, why not use something like the PIC24EP256MC20x that (I think) has the same high speed PWM and a QEI peripheral built in. UYou wil stil need to sort out the other issues but if you can get hardware to do the low-level grunt work then why not.
The way you have written the code (with a LOT of work being done in the ISRs) makes the next issue harder on you than it should be but any variable that is altered in an ISR and referenced elsewhere needs to be declared as volatile. This stops the compiler from thinking that it alone controls the value of a variable which can lead to all sorts of wrong calculations elsewhere.
Susan
(PS - this is based on a quick glance at the code files you have supplied - I may well have missed something but I'm sure about my comments on the use of doubles and trig functions.)

Thank you very much for your time and the feedback.

Aussie Susan said:

Looking at the document you refer to, there is a section on "Fixed Point Arithmetic" (page 18) that says the DSP used (a TMS320F240 - which is a 16-bit device running at 10MHz) is programmed using this number representation. They also show how to use a sign lookup table.

On the other hand, your code uses 32-bit double precision values all through it as well calls to trig functions.

Click to expand...

Yes you are correct i will try to use the look up table instead of the sine and cosine functions.

You are only running your MCU with a 20MHz clock which implies 10MIPS - according to the 'include' statement (which may or may not be the correct way to do this depending on the compiler) you are using the dsPIC33EV256GM106 so you can set the clock up to 140MHz or 70MIPS.
However, even running the clock up to that speed would not overcome the overhead of the 32-bit doubles and the trig calculations.

Click to expand...

Yes this also i will try to go upto 140MHz.

I can't see the .h files, nor a 'main' function or the config settings so that slows things down a bit to understnad what is going on.

Click to expand...

Sorry i forgot to attach them. I will do it.

I can see that you are triggering the PWM interrupt every PWM cycle but in the code that is called by the PWM ISR (which includes function calls that add overheads but they will be swamped by the other issues mentioned above) I'm not sure how often the various current and voltage values (I assume that is what those variables represent) change as that would seem to depend on the signal inputs to PORTA0 and PORTB0. My guess is that these are a lot slower than the 60uSec mentioned in the referenced document as the PWM base frequency. If so then you only need to perform the calculations when those input change, not on every PWM cycle.

Click to expand...

The currents are only read from the adc. The adc is configured in such a way that when pwm interrupt it triggers adc and reads the current values.

I'm guessing (again) that you are using the input comparative as a Quadrature Detector to know the rotor angle. As you don't seem to be using the DSP capabilities of the MCU you have chosen, why not use something like the PIC24EP256MC20x that (I think) has the same high speed PWM and a QEI peripheral built in.

Click to expand...

This micro unfortunately is not having the Quadrature Detector and hence using input capture module.

You wil stil need to sort out the other issues but if you can get hardware to do the low-level grunt work then why not.
The way you have written the code (with a LOT of work being done in the ISRs) makes the next issue harder on you than it should be but any variable that is altered in an ISR and referenced elsewhere needs to be declared as volatile. This stops the compiler from thinking that it alone controls the value of a variable which can lead to all sorts of wrong calculations elsewhere.

Click to expand...

Yes that is my mistake i will add volatile keyword.

Does the motor (or whatever) you are trying to control really need to have the currents read every pulse of the PWM? Are they changing THAT fast and by a such a significant significant amount?
I know the device you have does now have a QEI peripheral but, as I said, you don't seem to be using the DSP features of your chip so why not change to a chip that DOES (like the one I suggested).
Also do you really need to use 32-bit double precision floating point values. The more bits you need to manipulate with each multiplication/addition/etc then the slower it will be. The Ti device you are basing your design on uses 16-bit fixed point numbers so that each operation can use the hardware of the chip and not resort to needing much slower library calls. (Remember that you may write a '+' or '*' in your code but the compiler must translate that into a function call as the MCU cannot perform that operation on the data types you are using directly.)
Also note that they program in the DSP's assembler whereas you are writing in C. There are significant advantages and disadvantages in both approaches.
Susan

The first step in the algorithm as suggested in the document is to read the phase currents. Yes i will start implementing the DSP features of the micro. Yes as you said I do not require 32 bit calculations i will switch over to look up table.

electronicsman said:

Yes i will start implementing the DSP features of the micro.

Click to expand...

That will probably require a complete re-think of how you do your calculations and is not what I'm suggesting. the DSP capabilities of these chips is best suited to digital filters, DFT, correlation and similar calculations. I'm really not sure if they would help you here without a good deal of re-working the whole problem.

electronicsman said:

Yes as you said I do not require 32 bit calculations i will switch over to look up table.

Click to expand...

Be careful not to confuse the 32-bit calculations with the table lookup suggestion - they are completely separate.
Table lookup will allow you to not call the sin() and related trig functions - these can be REALLY slow.
On the other hand if you still add, subtract, multiply or, worst of all, divide) floating point values then you will still suffer measurable slow downs compared to using the MCU's instructions. The hardware add/subtract/multiply operations take 1 instruction cycle for 16-bit integer (or fixed point) values, and divide takes 18.
Compare that to 4 for a 'call' and 5 or 6 for a 'return' to simply call the 32-bit floating point function, let alone all of the manipulations required within that function.
I don't have exact figures (and they would almost certainly differ by compiler) but you could easily get a factor of 20 x (and probably much more) by dropping the 32-bit double and using fixed point values.
Susan

I am not getting how to implement the sine lookup table as per the document. Let us I use 0 - 255 array for sine look up table. So each element will be like 360/256 degrees apart or 1.40625 degrees. so my table would be some thing like this
Next step is let us say my encoder sends 1000 pulses for one revolution or 360. So for every count i have 0.36 degrees incremented. How should i match this 1.4062 with 0.36. I am confused. Can you please suggest. Should i go with approximation?