Alternative PWM Frequencies

[dauntless89]

I was reviewing the table in the Teensyduino FAQ section, or whatever it's called, that lists the ideal PWM carrier frequencies for each resolution setting. I am using PWM to control electromagnetic servos in my project, and need to maintain probably 12-bit resolution. The carrier frequency requirement has yet to be determined, but I had a couple questions regarding my understanding of how the PWM timers work in the T3.6.

It's clear that the ideal frequency is dependent on some internal timing parameter because clock speed is a factor. What is the formula for determining the ideal frequency at a given CPU speed and PWM resolution? If it matters, I'm using pins 29 and 30 (FTM2) and won't be using any others.

It's also clear that the listed values are a limit. Will deviating from these "ideal" frequencies impose an efficiency penalty on the processor? For example, if my 12-bit resolution's ideal frequency is ~14.6kHz, will setting it to 12kHz cause any kind of an internal harmonic or phasing problem that could effect the execution of the code? If so, can this be avoided by setting it to something that can evenly divide the "ideal" frequency? Say, 7.3kHz, 4.86kHz, or 3.65kHz?

Thanks.

 

[PaulStoffregen]

What is the formula for determining the ideal frequency at a given CPU speed and PWM resolution?

F_BUS / powf(2.0, bits);

See kinetis.h for details on F_BUS speeds (TL;DR = defaults to 48 or 60 MHz).

For example, if my 12-bit resolution's ideal frequency is ~14.6kHz, will setting it to 12kHz cause any kind of an internal harmonic or phasing problem that could effect the execution of the code?

Well, I don't know what you mean by "internal harmonic or phasing problem", but I can tell you the timer hardware is clocked by F_BUS. If you set the frequency higher than F_BUS / 4096, each PWM period will be composed of less than 4096 clock cycles of F_BUS. The analogWrite code will automatically scale your numbers to whatever number of actual steps the hardware can do. If you've used analogWriteResolution(12), this necessarily means some of the 4096 codes will map to the same PWM duty cycle, since you've configured the hardware for fewer than 4096 F_BUS clock cycles.

 

[dauntless89]

If I'm picking up what you're laying down, that would be the case if I tried to set it to something like 16kHz instead of 14.6. Basically you would lose effective PWM resolution.

What about going the other direction? I'm thinking it would lose a slight bit of timing accuracy due to the clock cycle of the timer not lining up with the PWM cycle, but that's not a problem for my project as long as this wouldn't effect anything else in the execution of the program. For example, my last round of testing on the device was at 13-bit and 400hz. The device operated as expected, but the program on the T3.6 is so simple there'd be no way to detect timing glitches as a result of those PWM settings.

Thanks for the formula and reply, I will review kinetics.h after work.

 

[PaulStoffregen]

If you're ok with the PWM steps not being perfectly equal, 400 Hz and 13 bit should work fine.

Assuming you're running with the default 60 MHz F_BUS, that means you'll have 37500 unique steps. A prescaler of 4 is used, since the timer is only 16 bits and can't do 150000 steps.

When you write numbers from 0 to 8192, they are mapped onto that 37500 range. If you sweep from 0 to 8192, some steps will use 4 timer cycles, which is a 2.67 us change in pulse width. Others will use 5, or a 3.33 us change in pulse width.

Of course, this is how the analogWrite() function works. If you dig into kinetis.h and fiddle with the timer registers directly, how you do so is completely up to you. But if you want things to "just work", you can simply use analogWrite() and analogWriteFrequency() and analogWriteResolution() to get pretty good results without all the pain of learning the complicated low-level timer registers.