Thanks Joep, I will take a look at these things. > What I see is a pulse of 1.53 (close enough) each 4.14 ms; way too fast!
>From my source: >http://www.horrorseek.com/home/halloween/wolfstone/Motors/svoint_RCServos.html The rate at which these pulses are sent isn't terribly important - only the width of the pulse. Some typical rates are 400 Hz (2.5 mSec pulse spacing) and 50 Hz (20 mSec pulse spacing). I am sending pulses at about 241 Hz - 295 Hz (according to your measurements). Seems ok to me. Do you have another source? > Then I changed the number of servo's from 2 to 1. and this changed the > rate to a 1.26ms pulse every 3,38ms. > For a user, this means that adding a servo to his application changes > it's behavior. This is not acceptable behavior for a library. As stated in the library notes, if you add servo's, you must re- calibrate the servo's min/max values. It is not difficult for a user to re-calibrate. Allowing the user to re-calibrate is most likely the best solution. Users will have many types of servo's, the library cannot be exactly correct for every type of servo. I have given step-by-step re-calibrate instructions to the user. I think this is acceptable. > And about the ISR time: this is about 5 us for one servo and 30 for 8 > servo's. Using 1 counter as I suggested before, reduces 30 to 26 > us.Leaving out the second condition (not elsif, just else), saves an > other 8 us. And finaly, 8 statements like: True, there will be less resolution with 8 servo's (less places for the servo's to move) because the ISR will take longer, but still works good after re-cal of min/max. did you try it with a real servo? I will have to add a note about this in the library. > I also measured the ISR pulse; this was not stable and switched > between 67.57 and 73.53 us, 5.96 us jumps (again: measured with an > oscilloscope, so not that accurate as a logic analyser). > The reason it jumps is due to the nature of timer0: it can't pulse at > a given interval like timer2 can, but requires manual reload each > time. So the time between the roll-over of the timer and the reload > influences the pulse rate. You could reduce (but not eliminate) this > effect by reloading the timer at the start of the isr. This will > probably remove the jumping effect when there are no other interrupts > available. The size of the jumps and overall accuracy can be reduced > with choosing a smaller prescaler value and load a larger offset. This 5.96us jump does not seem to move or make the servo jitter, but I will take a look at it. If I put the reload of the timer at the start of the isr, the timer may run out before the end of the isr (with 8 servo's). I may be able to move the reload to the middle of the isr but I don't want too many interupts. > IMO it would be better to reprogram a (16 bit) timer and only generate > an interrupt when there is an action, when you want many (say, more > then two and up to 8) servos. This will give only 9 interrupts each 20 > ms and will allow fine-grained control. In this case, I think one timer would be needed for each servo or two, so may not do it like this. Or maybe I don't understand, can you explain more please? I am currently testing I2C master/slave echo. The servo stay's stable with I2C interupts. I am still testing and will let you know my results. Matt. -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
