Our messages crossed... I think a servo library is usefull. Longer delays can be created by cascading timer delays,
Joep 2010/1/22 mattschinkel <[email protected]>: > Is this lib usefull or not? I think it's better then nothing. I would > like to know so I may either continue (and add more servo's) or scrap > the idea. Could this one be added untill a newer, better version gets > created? I don't mind removing my lib when a better version comes out. > I already have at least one other person using my lib whom says it > works great. I also think it will attract many users if I make a > tutorial. > > I would like to address the delay issue: > > Using the timer, there will be a max of 2.5ms delay. Is this really > that big of a problem? surely there is a better way, however, I have > noticed 1ms delay's in other libraries. For example, EEPROM writes > require a 1ms delay. > > Without a timer, the user can specify how long the delay will be after > the pulse. So, therefore, the user can specify 0 or 1ms delay after > the pulse. This would also make a max delay of 2.5 to 3ms. > > I could set this delay in the lib instead of allowing the user to > choose, but the main program it's self is a delay anyways, therefore a > 0ms delay should be available to the user. > > Matt. > > On Jan 21, 5:42 pm, mattschinkel <[email protected]> wrote: >> Yes, your right, it does stop your program for a min of 2.5ms (with >> the timer enabled). The number of times this stops your program for >> 2.5ms is up to you. For example, you can stop your program for 2.5ms >> (to send a pulse) every 5ms or every 100ms. >> >> The procedure without a timer would be usefull for PIC's that don't >> have timers, or of someone wants to use many servo's on an external >> PIC. This may not be needed if we can get 8 servo's on one timer. >> >> How can I get a timer to run a procedure when the timer is up without >> polling it? If start the pulse, and the user's program takes too long, >> it will move the servo to the wrong position. >> >> Anyways, at least this is a start. >> >> Matt. >> >> On Jan 21, 4:42 pm, Joep Suijs <[email protected]> wrote: >> >> >> >> > Hi Matt, >> >> > You are right, a servo lib is long overdue. The thing is, that its not >> > so simple to create a lib that properly supports a servo without >> > putting severe limits on you application. >> > The most critical issue is stability of the pulse. Even one interrupt >> > during the delay will move the servo (slightly). And applications that >> > use serial or i2c can't afford to disable interrupt for 2.5 ms. >> > What could reduce the chance of a disturbance is to use a timer for >> > the pulse. This way only a interrupt at the end of the pulse will give >> > a disturbance, not any interrupt. >> >> > If I look at your code, the use_timer version is useful and it could >> > be improved if the actual pulse is also timer-based. And multiple >> > servos could be supported (up to 20ms / 2.5ms = 8 servos). >> > The non-timer version is not very useful IMO. It blocks the cpu for >> > 20ms and must be called (almost) immediately after it returns. >> >> > I once saw a system that used a 10us interrupt to create servo pulse >> > timing. This is a heavy load (if feasible) for a pic. A more complex >> > but better solution would be to set a timer to the desired value for >> > each pulse and have it generate an interrupt. Maybe this gives a >> > smooth pulse with other interrupts and otherwise it gives a base to >> > work around this: most (all?) interrupt libs will work with the >> > specific IE flag false, if you poll the appropriate ISR continuously. >> >> > Joep >> >> > 2010/1/21 mattschinkel <[email protected]>: >> >> > > I have seen that many people on jallist are looking for servo control >> > > and have started a lib. Please have a look. >> >> > > Currently only supports one servo, but it should be easy to add many. >> >> > > Thanks, >> > > 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 >> > > athttp://groups.google.com/group/jallib?hl=en.-Hide quoted text - >> >> > - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > -- > 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. > > -- 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.
