The best way to control a servo with a PIC

[skimask]

Quick random thought...If you're used to using the 16F87/88, why not stick with them? They're only 4 pins more than the 'F688 discussed earlier...

Here's my addendum to the earlier post...
Say you've got a 'PWM counter' that runs from 0-2000 (actually a 20ms counter incrementing every 10 microseconds), you want desired_position '0' on the servo. Actual_Servo_Position = desired_position + 50 (0 in this case)...
if actual_servo_position < pwmcounter then servo-pin = 1, servo-pin will go high for .5ms (bare minimum for a servo probably), then be low for the rest of PWMcount until it resets itself.
or you want desired_position 2000 on the servo...
Actual_Servo_position = desired_position + 50 (2050 in this case)....same thing except servo-position will go high for 2.5ms (probably the absolute most), then be low for the rest of the count just like the other case...

You could easily put this in a tight little loop handling everything for you, reading the RCREG for any servo commands that come thru (or packets if you want to go that way) and still keep decent resolution on the servo itself.

[The Master]

Im not really used to the 16F87. I used to use 18F877As for testing everything and since looking at Matt's boxes a 16F84A. I found the 16F87 by using the search at Microchip.com. I think this project is the first time ive used it. I guess i might aswell stick with it. I might save more from bulk buying just that 1 chip than from buyng a smaller chip.

Im not completely sure i understand your last explanation. I dont think i can use the normal PWM code for servos because TMR0 overflows every 256 instruction cycles. 1 instruction cycle takes 200ns. That means TMR0 overflows every 51200ns or 51.2us. The pulse for the servo has a range of 2000us. If i divide 2000 by 51.2 then i get 39.0625. Thats the resolution i will get for the servo. I was hoping for 256.

I know i can do what i want by using pauseus. I tested that out before. I guess pulsout would work the same way. Idealy i dont want any serial data arriving during the short pulse. Just a few microseconds difference causes the servo to move out of place. The best thing i think is to do all the receiving and processing during the 18ms where the timing doesnt have to be so accurate. I think anything between 18 and 25ms is fine. If i use a 2 byte protocol as described above then there shouldnt be a problem. The PIC can buffer those 2 bytes and wait until the short pulse has finished. The main PIC can be set not to send data faster than that so hopefully everything should work fine.

I will breadboard all of this out first ofcourse. I just have 1 servo at the moment for testing. These lights arnt the same ones that ive been making but they work in pretty much the same way. There just bigger, brighter and move lol.

[skimask]

Im not really used to the 16F87....

Well, time to get used to something eh?

Im not completely sure i understand your last explanation. I dont think i can use the normal PWM code for servos because TMR0 overflows every 256 instruction cycles

It doesn't have to overflow every 256 instruction cycles... It can, in theory, overflow once every 8 instruction cycles if you want it to.
Now how would you accomplish that?

Idealy i dont want any serial data arriving during the short pulse.

If you're going thru that loop fast enough, grabbing a byte out of the serial port won't jack up the timing that much.
And like you said, the 18-25ms frame time is fine, as long as you're in the vicinity.
The critical thing would be the high pulse. Confine the critical code and you're in there...

[The Master]

Hmm, ive read the datasheet again. Aparently there is a register called TMR0. I cant seem to find any more information on that though. There is the prescaler but that does the oposite of what i want. I have heard that you can count how long something takes using the timer. Would you just have a loop and keep checking the current value? Is that value in TMR0? Ive not seen anything else about making the timer overflow at less than 256.

[skimask]

Hmm, ive read the datasheet again. Aparently there is a register called TMR0. I cant seem to find any more information on that though. There is the prescaler but that does the oposite of what i want. I have heard that you can count how long something takes using the timer. Would you just have a loop and keep checking the current value? Is that value in TMR0? Ive not seen anything else about making the timer overflow at less than 256.

TMR0 is a register... Is this TMR0 a read-only register? Is it a write-only register? Is it a read/write register?
If you can write to this TMR0 register as it's called, when can you write to it?
Can you write to it while it's running? Or do you have to write to it while it's stopped?
(I'm not dogging you at all...there's water around here somewhere...You just happen to be the horse )
And no, for this particular item, there's not a lot of DIRECT information in the datasheets, but there is quite a bit of 'read-between-the-lines' stuff that applies to all registers and applies here...

[The Master]

I didnt see the answer to any of those questions when i read through the datasheet. Ill do some more reading tomorrow and probably some more google searches.

[skimask]

I didnt see the answer to any of those questions when i read through the datasheet. Ill do some more reading tomorrow and probably some more google searches.

We don't need no steenkin' Google
TMR0 is a register just like almost any other register, like any other byte of ram in the PIC. It just so happens that this register is increment on every instruction cycle (or every other one, or every 4th one, or whatever you've set it up to do).
Does that help you out any?