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.Is it kind of ok or what shall i do since i want the calculations to be done at 30 microseconds.
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.
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.
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.
Yes this also i will try to go upto 140MHz.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.
Sorry i forgot to attach them. I will do it.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.
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.
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.Yes i will start implementing the DSP features of the micro.
Be careful not to confuse the 32-bit calculations with the table lookup suggestion - they are completely separate.Yes as you said I do not require 32 bit calculations i will switch over to look up table.
for(index=0; index < 255; index++)
{
sinelookup[index] = sin (2*pi*index/255);
}
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?