# Attiny85 and Atmega328 for RC projects

I am designing modules for radio controlled aircraft. Most of the time I have to read a PWM pulse and produce a PWM pulse between 1000 - 2000 microseconds. When I use an Atmega328 (@16 MHz with crystal) there are no problems but if I use an Attiny85 (@8 MHz internal oscillator) I get servo jitter (due to PWM pulse timing problems). My question is; Can this behaviour be explained with the difference between a quartz and an R/C oscillator? Thank you...

• How are you controlling the 20mS pulse width? – JIm Dearden Mar 24 '17 at 14:48
• The internal RC oscillator is fairly stable over short time periods (tens of seconds), though it's initial frequency accuracy can vary by +/-10% unless user calibrated. I'd be surprised if that is the cause of your problem. The ATMega328 has the same internal oscillator available as the ATTiny85, you just have to set the clock to 8 MHz using the CKSEL selector Fuse. See section 13.2 in the datasheet. I'd move your '328 to it's internal clock and get a more valid comparison of the two MCUs. – Jack Creasey Mar 24 '17 at 15:04
• In addition to other comments, you have to make sure you repeat the pulse every so often ($\le 20\:\textrm{ms}$, I think.) If you are pushing this limit (setting your timers so that you specify exactly that rep-rate), then you might also be causing troubles for that reason. If so, this is easy to test. Just set your software rep-rate to $\le 15\:\textrm{ms}$ and see if that helps with the ATtiny85. If it does not help, then look elsewhere. Also, do you have a scope? – jonk Mar 24 '17 at 18:07
• Pulse width is not 20 mS but the pause between the pulses is around 20 mS. This pulse repetition rate is not critical in R/C applications. So, a pulse every 16 - 25 mS is OK. In my projects the pulse repetition rate is defined by the incoming pulse most of the time. That means I read a pulse, I make the necessary calculations and then produce an output pulse. This leads to the same pulse repetition rate as the input signal but there is a slight delay. – Sumer Yamaner Mar 26 '17 at 12:13

Firstly, make sure you've not got the "CKDIV8" fuse set to 1, this will reduce your actual instruction clock rate to 1MHz if you're using the 8MHz internal oscillator. This is the default state of the ATTiny85 chip when it leaves the factory.

Furthermore...

You can set the internal CPU frequency to 16MHz (refer to "Table 6-4" in the datasheet) using the following fuses in the programming dialog...

• EXTENDED = 0xFF
• HIGH = 0xDC
• LOW = 0xC1

You can type those numbers in hex into the 3 text fields in the "Fuses" section of the device programming dialog, doing this will automatically refresh the list of checkboxes corresponding to the full set of fuses in the device.

If you adjust your code to compensate for the higher frequency, this might be enough to give you better pulse timing resolution.

I use these fuses when I'm driving NeoPixel LEDs, which require rather fussy and tight timings.

Alternatively as you suggested, you can simply use a an external crystal oscillator of up to 20MHz. As always, follow the datasheet and you'll be able to do this.

• For setting the fuses I am using the Arduino IDE. I am uploading a bootloader for Attiny85 @ 8MHz internal. This function simply sets those fuses correctly and I have verified that the micro runs at 8 MHz. I don't want to use a crystal with an Attiny85 because this would reduce the available ports and make the PCB bigger. – Sumer Yamaner Mar 26 '17 at 12:19
• Then you should try running it at 16MHz as I showed in my answer. This might give you enough extra resolution to meet your strict timing requirements. – Wossname Mar 26 '17 at 12:47

Can this behaviour be explained with the difference between a quartz and an R/C oscillator?

Possible but unlikely.

The jitter from a t.v. oscillator is in the sub us range. And nothing over the long term (ms range)

The processing, if done right, is going to be 100 to 200 ticks per edge. So roughly 400 ticks over a 20000 tick period, even if the Mic runs at 1Mhz.

So the issue is likely your software.

edit: i just tested it on a atmega328p running at 1MIPS. Generating 5-ch of concurrent and independent RC signals utilizes less than 6% of the mcu's processing power. or 1200 ticks / 6 -> 200 ticks per channel in a 20-ms period.

The approach is outlined here: https://dannyelectronics.wordpress.com/2017/02/18/driving-multiple-servos-off-a-pic-timer2-ranged-extended/