Post by thread:[PIC]: Controlling an R/C servo with a PIC

This time I won't ask any question, only to thank you all for helping me finish the first bit of my project and also tell you that I've created some documentation on how to interface a PC a PIC and a Servo together. The paper and all related material is in my website, if you care to look at it you'll find it at: http://www.merlotti.com/EngHome/Computing/software.htm Comments are welcome. Cheers Padu

Padu wrote : > This time I won't ask any question, only to thank you all for > helping me finish the first bit of my project and also tell > you that I've created some documentation on how to interface > a PC a PIC and a Servo together. > The paper and all related material is in my website, if you > care to look at it you'll find it at: > > www.merlotti.com/EngHome/Computing/software.htm > > Comments are welcome. Hi ! Well... :-) Not much to comment on that, is there ? I havn't read all details, but it sure look impressive ! Regards, Jan-Erik. PS. This is also a test of the piclist, since it hse been very quiet so far today...

Very minor comment, Padu. On Page 14, you mention that our timeslot is 20MS in order to be in compliance with the servo's 50 MHz refresh frequency. I believe you meant to say "50 KHz"?? Dennis Jan-Erik Soderholm wrote: {Quote hidden}>Padu wrote : > > > >>This time I won't ask any question, only to thank you all for >>helping me finish the first bit of my project and also tell >>you that I've created some documentation on how to interface >>a PC a PIC and a Servo together. >>The paper and all related material is in my website, if you >>care to look at it you'll find it at: >> >>www.merlotti.com/EngHome/Computing/software.htm >> >>Comments are welcome. >> >> > >Hi ! >Well... :-) >Not much to comment on that, is there ? >I havn't read all details, but it sure look impressive ! > >Regards, >Jan-Erik. >PS. >This is also a test of the piclist, since it hse been very >quiet so far today... > > > > >

One other point, Padu. At the end of you r paper, you mention a problem with jittery servo action when receiving a lot of serial data. It could be because both events (servo and serial) are handled via interrupts and you MAY be slipping timing on the servo somewhat if both interrupts happen extremely close together. I haven't studied your code to be sure, but I would make sure the most vital interrupt (servo) is processed first, then process the serial data. Make sure you do MINIMAL code processing in the interrupt - do what you absolutely have to, then get out!!! I might be wrong, but it seems to me to be more like a timing problem with the PIC than with Windows. Good luck! Dennis Jan-Erik Soderholm wrote: {Quote hidden}>Padu wrote : > > > >>This time I won't ask any question, only to thank you all for >>helping me finish the first bit of my project and also tell >>you that I've created some documentation on how to interface >>a PC a PIC and a Servo together. >>The paper and all related material is in my website, if you >>care to look at it you'll find it at: >> >>www.merlotti.com/EngHome/Computing/software.htm >> >>Comments are welcome. >> >> > >Hi ! >Well... :-) >Not much to comment on that, is there ? >I havn't read all details, but it sure look impressive ! > >Regards, >Jan-Erik. >PS. >This is also a test of the piclist, since it hse been very >quiet so far today... > > > > >

> sure, but I would make sure the most vital interrupt (servo) is > processed first, then process the serial data. That won't reduce the worst case. When the servo interrupt happens just after you did check the serial interrupt flag you will still have a latency equal to the serial interrupt processing. See it this way: what is most time critical? I assume the servo handling. Hence that must be interrupt driven. The main loop can just poll the UART as fast as it can. For correctness: prove that the worst case serial handling, interrupted as often as possible, will still poll the UART fast enough. Or maybe: (I did not follow this thread, so I might just be talking nonsense) I assume the servo code is interrupt driven for both the start and the end of the pulse. The pulse width itself is critical, the inter-pulse period much less. Is it enough to process serial data one per pulse, either before or (preferrably) after thye pulse? Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Ow! Yes... :-) Thanks for the catch! Padu ----- Original Message ----- From: "Dennis J. Murray" > Very minor comment, Padu. On Page 14, you mention that our timeslot is > 20MS in order to be in compliance with the servo's 50 MHz refresh > frequency. I believe you meant to say "50 KHz"?? > > Dennis >

Yes, 1000ms/20ms .--. .- -.. ..- ----- Original Message ----- From: "Jan-Erik Soderholm" <spam_OUTjan-erik.soderholmTakeThisOuTtelia.com> To: <.....piclistKILLspam@spam@mit.edu> Sent: Monday, February 07, 2005 1:39 PM Subject: RE: [PIC]: Controlling an R/C servo with a PIC {Quote hidden}> Dennis J. Murray wrote : > > > Very minor comment, Padu. On Page 14, you mention that our > > timeslot is 20MS in order to be in compliance with the servo's > > 50 MHz refresh frequency. I believe you meant to say "50 KHz"?? > > Whould I dare to guess 50 Hz ?? > > Jan-Erik. > > > > --

You are 110% right!! Don't know where MY brain is today! Obviously, better not try anything important or life-threatening!!!!! So I guess you might say the orignial writer's comment about 50MHz was a "million to one shot"?? ;-) Thanks, Jan-Erik! Dennis Jan-Erik Soderholm wrote: {Quote hidden}>Dennis J. Murray wrote : > > > >>Very minor comment, Padu. On Page 14, you mention that our >>timeslot is 20MS in order to be in compliance with the servo's >>50 MHz refresh frequency. I believe you meant to say "50 KHz"?? >> >> > >Whould I dare to guess 50 Hz ?? > >Jan-Erik. > > > > >

From: "Wouter van Ooijen" > See it this way: what is most time critical? I assume the servo > handling. Hence that must be interrupt driven. The main loop can just > poll the UART as fast as it can. For correctness: prove that the worst > case serial handling, interrupted as often as possible, will still poll > the UART fast enough. That's a good idea. Although in my project the jittery aspect won't matter because I won't be sending servo commands in such small increments and they will be spaced in time. Therefore I just stated the problem in my conclusion as inspiration for someone (or even myself later). > Or maybe: (I did not follow this thread, so I might just be talking > nonsense) I assume the servo code is interrupt driven for both the start > and the end of the pulse. The pulse width itself is critical, the > inter-pulse period much less. Is it enough to process serial data one > per pulse, either before or (preferrably) after thye pulse? This issue was addressed in another topic and I concour that it is the most reliable way to set the pulse with, but in my case that's not what I am doing. I am using interrupts to mark the start of the pulse, and then regular delays to create the pulse. I agree that it is a waste of processor time, but for this example it works. I would have to carry some experiments to determine if this decision is what makes it jittery, that's a good possibility that yes. Cheers Padu