# Hardware PWM on PIC

#### rjenkinsgb

##### Well-Known Member
If I'm correct, that the ENVELOPE is over 24ms,
That's because it is using a number of "channel" times, some real and some dummy ones, to get to the total time before it repeats.

The repeat time is not in any way critical; 20mS (50Hz) is a historical value, it's supposed to be somewhere around 40Hz to 200Hz repeat rate, so 5 - 25mS but that's not too critical with most servos.
Some do not like too high repeat rates and that can cause jitter.

If you want is slightly shorter, change this:

C:
    If index > 15 Then
//15 * average 1.5mS = 22.5mS, a reasonable frame repeat time

eg. changing 15 to 12 would reduce the cycle duration by 4.5mS

It will vary with total length of the servo pulses at that exact instant, though. That's the cost of not having any separate reset timing system.

Use 14 instead of 15 if you want it just slightly faster.

#### camerart

##### Active Member
That's because it is using a number of "channel" times, some real and some dummy ones, to get to the total time before it repeats.

The repeat time is not in any way critical; 20mS (50Hz) is a historical value, it's supposed to be somewhere around 40Hz to 200Hz repeat rate, so 5 - 25mS but that's not too critical with most servos.
Some do not like to high repeat rates and that can cause jitter.

If you want is slightly shorter, change this:

C:
    If index > 15 Then
//15 * average 1.5mS = 22.5mS, a reasonable frame repeat time

eg. changing 15 to 12 would reduce the cycle duration by 4.5mS

It will vary with total length of the servo pulses at that exact instant, though. That's the cost of not having any separate reset timing system.

Use 14 instead of 15 if you want it just slightly faster.
Hi R,
I was just looking at that //15 calculation!
I need 6xCH, RB0-5. RB6+ are used by PICKIT3, do the dummy CH effect anything?

As it is now, it is slightly too long, but is that acceptable? (I want to avoid jitter) I don't know what the boundaries are.

At the moment, I only have 5xCH, and just tried a SERVO on all of the CH PINS. All moved, repeated and no jitter.
C.

#### Nigel Goodwin

##### Super Moderator
Hi R,
I was just looking at that //15 calculation!
I need 6xCH, RB0-5. RB6+ are used by PICKIT3, do the dummy CH effect anything?

As it is now, it is slightly too long, but is that acceptable?
(I want to avoid jitter) I don't know what the boundaries are.
As already explained above, it's EXTREMELY non-critical - double would be fine, five times could well be fine - slightly too long doesn't matter whatsoever.

#### camerart

##### Active Member
As already explained above, it's EXTREMELY non-critical - double would be fine, five times could well be fine - slightly too long doesn't matter whatsoever.
Hi N,
Ok, thanks.
A lot has been said and often it is repeated, hopefully the repeats will not be needed eventually

I need 6xCH, RB0-5. RB6+ are used by PICKIT3, do the dummy CH effect anything?
C.

Last edited:

#### camerart

##### Active Member
Hi,
The SERVO wasn't moving to it's full range, so I changed [ servo_times(x) = 0600 ] and the other side to [ servo_times(x) = 2400 ] This worked, so is this ok?

I've re-read #121 and now can see the range.

Sometimes the SERVO does a bit of jittering.

Does high repeat range mean longer or shorter length of time?
C

Last edited:

#### rjenkinsgb

##### Well-Known Member
do the dummy CH effect anything?
The dummy channels just pad out the overall sequence to give a reasonable delay before repeating.

For normal servos the repeat should not be less than 10mS, so with 6 x 0.8mS (4.8) you need four extra 1.5mS padding cycles (6mS) to guarantee you reach that. So, minimum total count of 10.

Experiment with different values - it won't hurt anything!

OK on widening the time range; if it works with the servos you have, it's fine.
Just be wary that different makes/types may hit the ends of the travel and stall or overload if you go outside the 1-2mS range.

#### camerart

##### Active Member
The dummy channels just pad out the overall sequence to give a reasonable delay before repeating.

For normal servos the repeat should not be less than 10mS, so with 6 x 0.8mS (4.8) you need four extra 1.5mS padding cycles (6mS) to guarantee you reach that. So, minimum total count of 10.

Experiment with different values - it won't hurt anything!

OK on widening the time range; if it works with the servos you have, it's fine.
Just be wary that different makes/types may hit the ends of the travel and stall or overload if you go outside the 1-2mS range.
Hi R,
I think I've got it.
I've hit the buffers a couple of times.
I'll do some playing, then program some movement.
Interesting stuff, thanks.
C

#### camerart

##### Active Member
Hi,
I'm sure I was advised to set TRISD to all OUT, can someone let me know if this is correct, and why, please?
I'm trying to add the SPI setting, and think they are clashing.
C

#### Pommie

##### Well-Known Member
This seems to be the relevant bit in the datasheet,

Mike.

#### camerart

##### Active Member
This seems to be the relevant bit in the datasheet,
View attachment 137143

Mike.
Hi M,
I now remember that I set PORTB to '0' to see the 2x LED indicators (too lazy) I have set each BIT in PORTD, and it works as from 5mins ago, thanks.
C

#### camerart

##### Active Member
Hi,
REMOTE:
PIC 1, 18F46K20 READS and send peripheral DATA to a computer screen for testing, including Altimeter and Compass, also control DATA to '2'.
PIC 2, 18F4431 receives SPI DATA from '1' and controls the MOTORS/SERVO.

While '2' is being programmed the compass outputs DATA. While '2' is running the Compass stops outputting.
What could cause this?
C

#### Pommie

##### Well-Known Member
While '2' is being programmed the compass outputs DATA. While '2' is running the Compass stops outputting.
What could cause this?
I would suggest a noisy power supply caused by the motors. Try disconnecting the motors and see if everything works ok.

Mike.

#### camerart

##### Active Member
I would suggest a noisy power supply caused by the motors. Try disconnecting the motors and see if everything works ok.

Mike.
Hi M,
I'm testing with SERVOs, and have tried disconnecting, no difference.
In '1' I tried turning OFF the SPI to '2' no difference.
C

#### Pommie

##### Well-Known Member
If anything is using I²C then it can hang after a download as it can start in an unstable state. Could it be this?

Mike.

#### camerart

##### Active Member
If anything is using I²C then it can hang after a download as it can start in an unstable state. Could it be this?

Mike.
Hi M,
All SPI! There is an Altimeter also wired the same, which always works?

One possibilty, is: I made my own Compass PCB from and iphone compass chip, which needs attention (more caps etc)

C

Replies
7
Views
7K
Replies
1
Views
2K
Replies
19
Views
4K
Replies
15
Views
10K
Replies
2
Views
2K