Concurrent threads on a pic?

[Mike, K8LH]

Originally Posted by mramos1

Just an idea. Could you use a 1ms timer ISR and 16 counter bytes (one per pin), if byte is not 0, flip coresponding pin high, decrement the counter each time (if not 0). When zero flip the pin low and ignore it? Then feed the 16 bytes from you program, 20 is 20ms high then back to 0. Main program could track the delay times?

Or would this cause a power issue and why the delay routine is better?

Or you maybe need some blocking to let them get were they are going to?

No, he can't use 1-msec interrupts. He using 120 steps/msec which allows him to swing the servo 60 steps left (anti-clockwise) and 60 steps right (clockwise) of the center 1.5-msec pulse width servo position. You'd need 8.3-usec interrupts to provide the same resolution and then you might not have enough time in the ISR to tickle and toggle a counter and output.

[Mike, K8LH]

Originally Posted by HakBot

This is only what I've heard from others in the forum but most servos operate outside of the advertised range to some degree. The pulse width may also vary slightly from brand to brand.

1-2ms will work, but I would like the user to be able to adjust this in the pc side app that will run the servos. Most of the applications/controllers I've seen allow the user to give the servo a pulse outside of the normal range.

Makes the code a litte more complicated.

Yeah, that might complicate it a bit.

What's the range? Instead of going from 1.0-msec to 2.0-msec would you like to go from 0.8-msec to 2.2-msec? Still an overall 20-msec period?

Mike

[HakBot]

Ok, how does this sound?

Here are the steps I was thinking to control 2 servos at once.

1. determine the smaller pulse width for the 2 servos
2. set both pins to high
3. delay the smaller of the 2 pulse widths
4. turn the pin off corresponding to the smaller pulse width
5. subtract the smaller pulse width from the larger pulse width and delay that much
6. repeat for the next set of 2 servos until 8 sets are performed

All together the total pulses should be shorter than 20ms. In my pc side code I will control this by setting the min pulse width to .5ms and the max to 2.5ms.

Something like this pusedo code:

if(delay1 > delay2){
pin1 = 1; pin2 = 1;
Delay(delay2);
pin2 = 0;
Delay(delay1-delay2)
pin1 = 0;
} else {
pin1 = 1; pin2 = 1;
Delay(delay1);
pin1 = 0;
Delay(delay2-delay1)
pin2 = 0;
}

I like this idea because it allows me to keep the interrupt timer in control of the overall period and have smaller or larger pulses. Does anyone forsee a problem with this code? I have a feeling that the extra logic will not effect the times by much (at least not enough to notice).

[Mike, K8LH]

That should work but I have one qualifier; you need to account for the case where delay1 = delay 2.

[HakBot]

I think that should be ok since it is using an if else. If they are equal then it would go into the else block. The second Delay should get passed up. I know there will be a few clock ticks in between there but should that matter much when dealing with millisecond delays?

} else {
pin1 = 1; pin2 = 1;
Delay(delay1);
pin1 = 0;
Delay(delay2-delay1) <-----shouldnt wait if they are equal
pin2 = 0;
}

[hjames]

I'm kinda confused as to why this stuff is being implemented as busy-waiting loops when the chip (A PIC18F4550, right?) has 4 separate timer/counter sections? It would seem much more reasonable to use a timer interrupt to schedule the transitions accordingly, plus you'd end up with some pretty insane resolution.

- i.e. set TMR1 to -1000, and you'd get an interrupt in 1000 timer ticks.

[HakBot]

hjames,

Because I'm not really sure how to do that. Delays are pretty straightforward. Do you have any example code that I could look at that uses the method you describe?

[hjames]

Well, think of it as a learning experience - learning how to use all the modules in there is a definite bonus.

Page 133 of the PIC data sheet has some sample code and a sample ISR for a RTC timer where they force TMR1 to 0x8000 every time the interrupt is called - which causes an interrupt in another 0x8000 ticks

But in general, just set TMR1 (all 16 bits) 65536 - "# timer ticks" (and since 65536=0, it's just -#ticks), and you'll get an interrupt at that time. Or you can read up on the "capture/compare" stuff and use some of the PWM logic. I can't give you more details without sinking a lot my time (I usually work with the Atmel chips), but I'd be real surprised if it isn't pretty simple.

As for structuring the code, I'd probably break it down into a state-machine like representation to keep the ISR simple. At the start of every frame, caclulate all the delays you need, and then enable the interrupts. The ISR would just do three things : 1) load in a new TMR1 value 2) update the ports with some precalculated values 3) decide whether it needs to execute again, or can shut down and disable it's interrupt.

[mramos1]

Originally Posted by Mike, K8LH

No, he can't use 1-msec interrupts. He using 120 steps/msec which allows him to swing the servo 60 steps left (anti-clockwise) and 60 steps right (clockwise) of the center 1.5-msec pulse width servo position. You'd need 8.3-usec interrupts to provide the same resolution and then you might not have enough time in the ISR to tickle and toggle a counter and output.

The 1ms timer ISR (I mentioned before) can be set to any resoultion (I jumped in late and just picked 1ms for the ISR for the idea). But still load a counter byte for each servo to move them (in usec for this case).

I think a timer ISR (based on the resolution he needs) and byte counter for each pin to move the servos will work. Just he needs to wait (block the pin) for each servo to settle before he updates the bytes counters.

[Mike, K8LH]

I admit I've become very curious about Servos during all the recent discussions. I wouldn't mind 'playing' with one to see how much resolution between 1.0-msecs and 2.0-msecs (or 0.5-msecs and 2.5-msecs) is useful or perceivable.

I too would prefer an assembly language solution using timers and interrupts but I simply don't have time for a new challenge right now (grin).

Have fun guys. Mike

[jpanhalt]

With current mid-priced transmitters and servos, such as Multiplex EVO and Hitec servos, the smallest change you can see empirically (i.e., 1 click on the trim) is about 25 us +/- 5us.

I just completed my previous servo project based on the 628A. For my next project, I would like more (at least 2; 3 preferred) PWM channels. Do you have any experience with the 16F886?
Thanks.
John

[Nigel Goodwin]

Originally Posted by jpanhalt

With current mid-priced transmitters and servos, such as Multiplex EVO and Hitec servos, the smallest change you can see empirically (i.e., 1 click on the trim) is about 25 us +/- 5us.

That's interesting! - that's only 40 steps for the 1mS maximum change.

Using a 20MHz PIC, and 25uS timer interrupts, it should easily be possible to do this for 16 servos

I just completed my previous servo project based on the 628A. For my next project, I would like more (at least 2; 3 preferred) PWM channels. Do you have any experience with the 16F886?
Thanks.
John

The hardware PWM isn't really great for driving servos, it's more common to di it in software - obviously a LOT depends what else is going on though?.

[jpanhalt]

That's exactly why I used PWM for the servo. The processor is handling several inputs and outputs. It holds servo position very steady while I do other things in the program. The next project will use the second PWM for a more typical, half-bridge motor control at 20KHz with soft start. Hence, my interest in a chip like the 16F886.
Regards, John

[zkt_PiratesDen]

Xor, at the Mikrobasic forum wrote a multiple servo controller program for 8 or 16 servos( dont recall which) in Mikrobasic. Dont know anything about it personally but there was a lot of interest it it.
zkt

[Mike, K8LH]

Originally Posted by jpanhalt

Do you have any experience with the 16F886?
Thanks.
John

I can't seem to find info' for the 16F886.

Mike

<added>

I found it listed as Future Product. How can anyone have any experience with it if it's not available yet (grin)?