Your ISR handler code will be more than 2 cycles: The CPU needs to push some registers (6) to stack, execute your code, execute thr return instruction which pops off the registers again.
My experiences were: 2000 interrupts per second with a reasonable handler on a PSoC4 runs smoothly.
Let us look at your problem from another point of view: Steppers run with 100 to 1000 steps per second. When you want to increase the PWM frequency after every step you will be with two motors (even with tree) on the right side. Lean back ;-)
On a PSoC 5 you may think about to develop a UDB-based component using Verilog hardware definition language. This component should do the speed ramp calculation and limiting all by itself. Complicated job, but it will in the end run without any CPU intervention, just setup, fire and wait until done.
Thanks. I've been working on a Verilog implementation for a trapezoidal ramp. I'm using micro-stepping and the minimum pulse width the stepper driver works with is 1us so I figured that a 500KHz pulse train is comfortable thus the need to ramp up to it- I have an appropriate gearbox ahead of the stepper so losing torque with speed isn't an issue.
I was just really curious to know what refresh rate I could get with ISRs alone as the cortex-M3 is well suited for back to back ISR execution and since the arduino can handle 4000 interrupts a second I figured that a cortex-m3 at more than twice the clock speed would have a much higher tolerance but I don't how much. Think I'll just use the systick timer to figure out how many cycles my ISR takes.
1 of 1 people found this helpful
To check how many CPU clocks spent to rise ISR and time inside ISR you can use StopWatch custom component, which can be found in this thread: