Has anyone ever had joy using PWM13-PWM16 for motor controllers?
I believe these are slow refreshed PWM outputs. Also they can glitch if there are conflicts with the interrupts.
We are currently using them as our motor controls, we are having a problem right now if we start the bot with camera off it turns in circles :(. While it tracks it kind of twitches, is that what you mean by the glitch if it conflicts with the interrupts Gdeaver? If so, you just made my day, couldn’t find the twitch anywhere in the camera or tracking code.
Actually, they are the fast (7ms update possible, vs. 26.6ms update) PWM outputs, but they require a call to
Generate_PWMs(pwm13, pwm14, pwm15, pwm16); every time you want them updated.
They can glitch with interrupts, but I have never seen this happen personally. 
I will try commenting out sections of the interupt code on monday, to see if I can locate the glitch, I’m also wondering if theres any chance of a conflict between cmuCam2’s TTL input interfering with high port numbers for motors? We are generating the pwms each run through the code as you have written above, and it seems are problem with a slight twich is associated with the camera tracking or initializing, but I have yet to pinpoint what in it, and it seems no one else has had this problem yet…
I have seen a similar issue with the servos on the camera. I had them connected to PWM 1 and 2, and when I accidentally discharged static to the chassis of the robot, or connected the serial cable to the program port, the servos would twitch, big time. This doesn’t prove to be an issue with the tracking code, though. I have never connected anything to 13-16, though. I use 16 to power the camera. That’s probably all it’s good for…
I remember reading somewhere that the new master code cures a twitch, but I don’t know if it’s the 13-16 issue, and I haven’t upgraded, so I don’t know.
Good luck,
JBotAlan
Our lead programmer wrote his own PID code. In testing, nothing worked right using the high PWM ports. He used Generate_Pwms, too. When we moved the control to PWM 3 & 4, it started working. No worries, it only cost us a day…
Check me but the lower PWM ports are controlled by the master proc. the high ones are software generated by the user proc. Interrupts are almost guaranteed to affect the upper PWM ports.
We’ve had some wacky stuff happen on ports 13-16. I would recommend forgoing them altogether.
So, if we are using encoders, which use interrupts, to control speed on the four high PWM ports, which are interrupt-sensitive, we aren’t just shooting ourselves in the foot, but actually firing an M16 on full auto directly into our arch, right?
Just say no to PWMS 13-16.
Never used them, never will.
They seemed like a good idea at the time…
:rolleyes:
We’ve been using pwm16…
…for camera power. 
Guilty:o
I’ve been reading that the camera is intended to run off the backup battery. Do the PWM ports provide the right voltage for the, you know, camera?
The servo power on the pwm output pins comes from the backup battery.
If you run those pwms on interrupts, does anything go wrong?
How about high priority interrupts? Can the function run fast enough?
Actually the Pwm’s 1-12 are 17ms speed normal refresh rate while the Pwm’s 13-16 have a 2 ms refresh rate. Victors can work with the fast 2ms refresh rate, servos can’t.
I think the Pwm’s 13-16 are hardware generated from pins called CCP1, CCP2,…
I don’t understand how these can be affected by the software?
The values are in software but if the software is slow to execute then the value just won’t change really fast.
For these pwms 13-16 alone, the software gets direct control to generate a timed pulse of between 1 and 2 ms duration, 1.5ms being neutral.
Any interrupts, interrupt the software timing these pulse widths, but the software doing the timing doesn’t know this. Just like none of your other regular code is ever aware an interrupt has occurred. So the software happily generates what it thinks is a neutral pulse of 1.5ms, but any interrupt handler that pops in, suspends the execution of your code, does it’s thing, and returns control will extend or stretch the time of your pwm pulse by the amount of time it took to service that interrupt.
So instead of a 1.5ms pulse, for example, you’ll end up with a 1.8ms pulse.
And your robot drives away.