The best way to control a servo with a PIC

[The Master]

Is PULSOUT a blocking command? I always thought it stopped your code like a pause command but im guessing not now youve mentioned it.

Edit: Just had a quick read of the online manual (im not at home with my proper one). It doesnt mention anything about it blocking/not blocking. Im sure ive read about it before though because i remember the resolution bit

[rmteo]

A single PIC18 @ 20MHz can control 24 servos with 256 steps:
http://www.mikroe.com/forum/viewtopic.php?t=6192

[The Master]

Im using a 16F (PIC16F87 to be more specific) @ 20MHz. Im sure it could handle 24 servos even with the way i did it. The problem is that the way i was doing it would have caused problems with the PWM for the LEDs. If PULSOUT allows the next few lines of code to run before it toggles back off then this should be really simple. I dont have anything to test on at the moment but when i get home ill give it a go

[skimask]

Is PULSOUT a blocking command? I always thought it stopped your code like a pause command but im guessing not now youve mentioned it.
Edit: Just had a quick read of the online manual (im not at home with my proper one). It doesnt mention anything about it blocking/not blocking. Im sure ive read about it before though because i remember the resolution bit

Yes, PULSOUT is a blocking command. As are PWM, SERIN(2)/SEROUT(2), POT, and so on.
Basically, anything that 'bit-bangs' a function is a blocking command. Nothing else can happen until that command is done.

I'm with you on this one... Send out your servo position data to a 2nd PIC via serial (or whatever) and have that 2nd PIC handle the servo positioning. There are a bunch of boards out there that do exactly that...can't think of any off hand, but I know I've seen them a bunch of times...

[T.Jackson]

Yes, PULSOUT is a blocking command. As are PWM, SERIN(2)/SEROUT(2), POT, and so on.
Basically, anything that 'bit-bangs' a function is a blocking command. Nothing else can happen until that command is done.

That's called a "synchronous" operation.

Asynchronous is a "do together at the same time" with something else operation.

[skimask]

That's called a "synchronous" operation.
Asynchronous is a "do together at the same time" with something else operation.

Thanks for clearing that up there Sparky...
I was kinda wondering when you'd get in there with the proper terminology and all...

[The Master]

Oh, I thought it might have been simple for a moment there. Since im using 16F i only get 1 hardware UART to play with but im using a MAX485 chip and in the lights the PIC controls the master/slave pins (the 555 method is only used in the main controller). So i can send data to a second chip without it being sent outside the light. I also have 2 spare IO pins so if i use a PIC chip to controll it i can tell it to only listen for serial data if an input pin goes high.

Now i just have to think of something to do with all those extra IO pins on the second chip. I dont think you can get anything with less than 12 and A/E/USART

[skimask]

Oh, I thought it might have been simple for a moment there. Since im using 16F i only get 1 hardware UART to play with but im using a MAX485 chip and in the lights the PIC controls the master/slave pins (the 555 method is only used in the main controller). So i can send data to a second chip without it being sent outside the light. I also have 2 spare IO pins so if i use a PIC chip to controll it i can tell it to only listen for serial data if an input pin goes high.

Now i just have to think of something to do with all those extra IO pins on the second chip. I dont think you can get anything with less than 12 and A/E/USART

I've used the 16F688 quite a bit, smallest PIC you can get with a built-in USART as far as I know. And if you set it up right, you should be able to run a load of servo's with it...If you set it up right...
Just a really simple idea off the top of my head...some pseudo-code if you will...

servo1 var porta.whatever...a lot of servo's...
...serial port setup...

loop:
....check RCREG for new data which is in this format...
bit7 = 1 = new data actually here, =0 nothing really here :)
bit6-bit4 = servo select, one of eight
bit3 = direction
bit2-bit0 = 3 bits to define the amount to move...

...now it gets a bit tricky...depending on clock speed of the PIC

...do the same thing with the servo's that you did with the LEDs, except the servos are on for XXX microseconds, and off for about 18ms or so...

goto loop

[The Master]

I was planning to do something similar to the LED code but i was going to use a whole byte for the position to simplify all of the code. The first chip can then pass a byte right from the buffer i already have for the LEDs and the second can turn the output on for an amount of time that is directly proportional to the value of the byte.

I think the best thing to do is have the servo PIC make one of its pins high during the 18ms of waiting. The LED PIC can only send data while that pin is high. I can use TMR0 to get the 18ms and a simple pauseus or pulsout command for the short pulse.

Ive checked both Rapid and Maplin for a 16F688 but they dont stock it. Can you buy directly from Microchip? It might be worth buying from elsewhere if the chips are going to be that much cheaper than the next best thing that Rapid stock.

I only have the need for 2 servos at the moment but i may need 3 for some other projects. I think thats about it though

[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.