casainho wrote: What will be your next steps??
I'll try to add interrupt handlers for the PAS and the speed signals to derive the duty cycle value from wheels rpm, cranks rpm and crank torque (read in from throttle pin)
) = factor x torquehuman
x rpm crank
I would avoid interrupts and why: I started to structure the code using different interrupts but I found they take to much time for the STM8 call and return them -- also I played with the priority of them but found that don't work as I expected -- the issue is that the fast loop motor control code needs to run at every 64us and any other interrupt seems to worst / delay the fast loop/PWM interrupt, which should be the top priority of the system.
What I am doing is using a timer on main loop and I will try call first in the loop the most priority code and counting the timer millis() -- I am doing this already to read the throttle value and do also the cruise control. This code do not interrupt the motor fast loop.
For code that needs to run each PWM cycle, I call it on the PWM interrupt or at multiple of the cycles.
For instance, I had interrupt for the pins of hall sensors signals and I removed the interrupt and I read instead the pin value at each PWM cycle. Anyway, later, when having motor code stable, we can measure all the times to understand all this things and see what is better.
But I think we should increase the PWM frequency if possible, to improve motor control for higher speed motors, and that means to optimize most as possible the PWM interrupt / motor fast loop.
For digital PAS signals, I would not use the interrupt of pins but the PWM / motor fast loop -- again, an pin interrupt would eat time of PWM / motor fast loop and probably be a source of instability on the motor control. If it is done on PWM cycle and with a known processing time, should be no issue. I would say: on PWM cycle looking for pin change value and flag / reset a timer variable; on main loop, look at the timer variable to find the PAS frequency and process it.
GREAT!! Now I understand your motivation -- and I am tuned with you!! Making the firmware OpenSource as also documentation about the hardware, developers/hackers will be able to make new things!! -- and closed source firmware makes the systems very rigid and you need flexibility for your project / adding support to S06S/Kunteng KT controllers for the torque sensors.