The AVR is similar to every other microcontroller in that is has a clock, I/O ports, a power supply or two, and needs to be
physically mounted to something to keep the circuit from falling apart. These topics will be briefly covered here for those
who are not familiar with them.
Power supplies are often taken for granted. The reason is that with the integrated circuits available the problems of the past
are mostly gone. There are still a few things to keep in mind, though.
Voltage Stability
You can't just hook up a transformer and a diode to the thing and expect it to work. The actual voltage may not
matter much, but whatever it is, it has to stay at the same level all of the time. There are a gazillion transistors
in there firing at voltages proportional to the power supply voltage. If it moves around, so does everything else.
Noise
You have to use bypass capacitors on the power supply and ADC reference pins. Noise will affect the results of any conversion.
If you don't care whether the conversions are totally accurate, or you aren't using the ADC, you don't need to worry about the
capacitor on the ADC reference. If you don't care if your micrcontroller freaks completely out and jumps to some odd address,
or resets with no warning, or just plain locks up, you can also leave out the power supply bypass capacitor(s). It does happen,
and you can spend a lot of time debugging problems that are caused by the lack of a bypass capacitor. They cost a couple of
cents. You should use them.
Efficiency
An AVR by itself uses little power. The ATtiny13a at 5V and 10MHz uses 0.8mA, or 4mW. At 3.3V, it uses 0.4mA, or 1.3mW. That is misleading.
Rarely does one build a circuit for an AVR that consists of the microcontroller with no connection to the ouside world. It would serve no
purpose. Lets add a 10mA LED to the mix. The power at 5V goes up to 54mW, or 13.5 times the power consumption. But what about the circuit as
a whole? What does the power input see the consumption as being? If you are using a 12V wall wart and a 5V regulator, and you have your LED on,
you are drawing 130mW. To the average hobbyist building a circuit with a mains connected wall wart, power consumption only begins to matter
when it approaches 10W or so. To the guy building a circuit that runs from a lithium battery, it does matter. A switching regulator might be
in order, since it will be much more efficient than a linear regulator. The switching regulator may be more complex, and more expensive, but
it may also be the thing that makes your project viable.
The power supply can be a make or break for your project. Consider it well. It may be that a 7805 with a couple of capacitors is all that is required, and most
of the time that is the case, but once in a while you might need to turn to a more advanced regulator to solve the power problem.
The reset circuit on an AVR is active low. When the reset line is low, the microcontroller is in the reset state. When it goes high, the microcontroller
starts a timer, the length of which is determined by fuses. The internal reset is deactivated after the timer expires. This allows the power and oscillator
time to stabilize. A side effect is that noise on the reset line during the transition from low to high will not affect anything, other than to extend
the time the processor is in the reset state. There is an internal pullup on the reset line, so you can just
let it float, but watch out in really noisey environments. Don't tie it to Vcc or you can't program the device in system, since you can't pull the reset
line low while power is applied. You will have to make a separate environment in which to program the device. Not really much of a problem if you want to
keep the target complexity down. I have a board with one each of every type of DIP packaged AVR, and I use it to program devices that are to be used in
applications which don't support in system programming.
Typical Reset Circuit
I always use a 10k resistor between reset and the supply. I also use a reset switch. Not for normal use, but for use while debugging. Contrary to other designs,
don't use a capacitor on the reset line. It will complicate programming the part, and is not normally needed. Also not needed is a diode to Vcc, which would only serve
to quickly discharge the capacitor that is not there. Since reset is static, the clock does not need to be running to reset the part.
The reset circuit on the AVR is really one of the better ones. It is simple and forgiving.
The initial accuracy of the internal RC oscillator is stated as ±10% from the factory. It can be calibrated by the user to an
accuracy of ±1%. The OSCCAL register is used by the AVR to calibrate the RC oscillator during reset. Exceeding the rated value
(overclocking) may result in write failure in the Flash and/or EEPROM. This table, from Atmel AVR053 application note, shows the initial
frequency of the internal oscillators for several devices. See the device datasheet for specific values.
Calibration
The default RC oscillator calibration byte in most devices automatically loaded from the EEPROM Signature Row and copied into the OSCCAL
register at start-up. This value can be changed by the user by following the calibration steps in
AVR053.
If you choose to use the internal oscillator,
but need it to run faster, you can reprogram the lfuse and remove the clock divisor. Be aware that the bit in lfuse that controls the oscillator divisor is not the
same in all devices. Also, you need to know that you can program the lfuse for no clock divisor and prevent the microcontroller from working in your circuit.
The maximum allowable clock frequency of any AVR decreases with the power supply voltage. The default divide by 8 clock is designed to run with 1.8V, but the
non divided clock will not run at that voltage. If you have changed the lfuse, you may have to increase the voltage in order to put it back the way it was!
Crystal Oscillator
Choice of crystal frequency
Crystals are high precision resonant components which are used with the XTAL1 and XTAL2 to form a very stable oscillator. The
frequency should be chosen to satisfy the requirements of your project, but must not exceed the maximum clock frequency at the
voltage at which the AVR will run. For instance, if you are trying to process as fast as possible, you would use a 16 MHz or 20
MHz crystal and Vcc=5V. If the job requires high speed serial communication, you would choose a 14.7456 MHz crystal. If you
require a lower Vcc, like 3.6V, be aware that the maximum clock speed will be lower. Consult the datasheet for the exact values.
AVR microcontrollers should have parallel resonant AT cut crystals. Using a series resonant crystal will result in a slightly
different frequency. Most microcontroller crystals are AT cut parallel resonant. lower frequency crysals, like 32.768kHz clock
crystals have a different structure. They will be covered below.
Connection to AVR
The crystal hooks to the two XTAL pins on the AVR. Two equal value load capacitors go from the XTAL pins to ground. This circuit should
be compact, and the ground line should go back to the AVR GND pin. This will keep noise off of the clock and help prevent errors due to
missing or extra clock cycles.
Load capacitors
The load capacitance listed in the crystal datasheet is used to calculate the size of the load capacitors according to the following
formula:
CL=((C1 x C2) / (C1 + C2)) + Cstray
I calculated the following table, assuming 3pF stray capacitance. If you suspect your stray capacitance is higher, add the additional
stray capacitance to the value for C1 and C2 in the table.
Cload (pF)
C1 & C2 (pF)
8
10
9
12
10
14
11
16
12
18
13
20
14
22
16
26
17
28
18
30
19
32
20
34
21
36
22
38
23
40
24
42
26
46
27
48
28
50
29
52
Choice of crystal frequency
Crystals are high precision resonant components which are used with the XTAL1 and XTAL2 to form a very stable oscillator. The
frequency should be chosen to satisfy the requirements of your project, but must not exceed the maximum clock frequency at the
voltage at which the AVR will run. For instance, if you are trying to process as fast as possible, you would use a 16 MHz or 20
MHz crystal and Vcc=5V. If the job requires high speed serial communication, you would choose a 14.7456 MHz crystal. If you
require a lower Vcc, like 3.6V, be aware that the maximum clock speed will be lower. Consult the datasheet for the exact values.
AVR microcontrollers should have parallel resonant AT cut crystals. Using a series resonant crystal will result in a slightly
different frequency. Most microcontroller crystals are AT cut parallel resonant. lower frequency crysals, like 32.768kHz clock
style="border: 1px solid black;">
30
54
Of course, these are not standard values, so you will need to adjust the table values to match the values you can get. Expect a shift
in frequency of a few parts per million due to capacitance mismatch.
32.768kHz Crystals
"Low frequency crystal" on most AVR's means one thing - 32.768kHz watch crystal. The load capacitance for these crystals is partially
made up by internal capacitors on the XTAL1 and XTAL2 pins. To calculate the required external capacitors, use this formula:
Ce = 2 * CL - Cs - Ci
where:
Ce - is the external capacitor
Ci - is the pin capacitance (XTAL1 = 18pF, XTAL2 = 8pF on ATmegax8)
CL - is the load capacitance for a 32.768kHz crystal specified by the crystal vendor
Cs - is the total stray capacitance for one TOSC pin.
For example:
If Ci = 18pF, CL = 12.5pF, and Cs = 3pF, to calculate C1:
Ce = 2 * 12.5 - 3 - 18
Ce = 25 - 3 - 18
Ce = 4pF
If Ci = 8pF, CL = 12.5pF, and Cs = 3pF, to calculate C2:
Ce = 2 * 12.5 - 3 - 8
Ce = 25 - 3 - 8
Ce = 14pF
Some AVR's (ATmega128) have 32.768kHz crystal oscillators in addition to the standard XTAL1 and XTAL2 oscillator. These oscillators are
optimized for 32.768kHz crystals, and no external capacitors are needed.
Ceramic Resonators
Choice of resonator frequency
Ceramic resonators are medium precision resonant components which are used with the XTAL1 and XTAL2 pins to form a fairly stable oscillator.
The frequency should be chosen to satisfy the requirements of your project, but must not exceed the maximum clock frequency at the
voltage at which the AVR will run. For instance, if you are trying to process as fast as possible, you would use a 16 MHz or 20
MHz resonator and Vcc=5V. If you are running at Vcc=3.6V you may only be able to use a 10 MHz or lower resonator.
Frequency tolerance
Ceramic resonators have a much higher variance than quartz crystals. Typical frequency tolerance of a ceramic resonator is 0.5%. There
are some tight tolerance devices which have as little as 0.1% variation, for use in USB devices and musical instruments. Temperature
stability runs from 0.08% to 0.4% across the temperature range. Since a ceramic resonator has a lower Q than a crystal, it is easier to
pull it off frequency, so drift with temperature and load is common. They are particularly susceptible to frequency variation due to
incorrect load capacitors. For many applications the ceramic resonator is adequate, but for some communication and process control
applications it may not be suitable.
Connecting a resonator to an AVR
The majority of ceramic resonators are 3-lead devices which contain built in load capacitors. Some devices are 2-lead, and require
external load capacitors. In either case, they connect exactly like a crystal circuit. The fuses must be programmed to use the
resonator, rather than the crystal or internal clock.
External Clock
Why an external clock?
The external clock option is intended to run the AVR from any compatible clock up to the rated speed of the device. You would select
the external clock option if:
You need a particularly accurate or stable frequency only available in an oscillator module
You want to syncronize several processes in the system to the same clock
You have an existing clock source that you would like to leverage to save the cost of the crystal and capacitors
It is possible to get oscillator modules that are more stable than the oscillator in the AVR. Some aplications may require that additional
stability. It is also possible that in a system with multiple clock users, performance is increased by synchronizing clocks. For instance,
under ideal circumstances the possiblity exists that communication between multiple microcontrollers can be done at higher speeds with
synchronized clocks.
Using the external clock
The external clock is selected by programming the appropriate Flash fuse bits. Think it through, though. If you program the fuses for external
clock, and you don't have one in your programmer, you will not be able to program the device again until you supply a clock. If you use ISP,
and have a clock on the board, you will not encounter this problem.
The AVR port output drive is more or less symetrical. The output current is dependent on the supply voltage, and is as high as 20mA with a 5V supply,
but drops to 6mA with a 1.8V supply. You can't drive the typical LED from a pin if the supply voltage is less than 3.3V, because there is not enough
output voltage to exceed the LED's forward voltage at the current required to illuminate it. Since lower voltages are used for lower power consumption,
it is likely you wouldn't want an LED on a 1.8V circuit, anyway.
If you want to drive anything with more than the 20mA available, you are going to have to use an external transistor to drive it. Also, if you are
going to drive anything inductive, like a relay - even a little 5V relay - you are going to want to use a transistor, too. The AVR cannot handle the
kickback from the coil, and the diode protection may fail. The transistor may have to be bipolar because larger MOSFETs require more voltage to turn
on than is available from lower power supply voltages. For instance, the IRF520 requires 4 volts to start conducting, and then it can't sink any
current to speak of. The IRF7470 and other "logic level" MOSFETS have very thin gate insulation allowing for turn on voltages as low as 2 volts.
If you are driving an analog (PWM) device and need some power, the L165 power OP-Amp may be what you need. I have used them for servo motor controllers,
with good results.
There is a certain amount of danger involved - anything that happens at the switch happens at the AVR pin. The most obvious thing
is static discharge, but anything can happen. The other main issue with switches is that they have springs in them, and springs
bounce. The switch may make, then break the connection many times before settling down to one state. The following circuits attempt
to solve these problems, starting from a minimal solution, and getting more reliable and safe.
First, I have to say that single-ended software debouncing, that is reading the switch multiple times to determine the state of the
switch is not recommended, except when the readings are several mS apart, and then only with option 1 below. This method is not
considered safe, and should be avoided when possible. If it matters, design for safety up front. If you are making a toy that does
not do anything critical, and you have the patience for odd switch behavior, by all means do simple software debouncing. Also, use
of the internal port pull-up is not recommended for critical signals, as it has high (20k to 50k Ohm) resistance, and more importantly,
can be switched off in software.
Software debouncing
With no debouncing circuitry a switch could send tens or hundreds of pulses to the microcontroller before settling down to a known state.
The software must see all of this as a single, well defined event. There are several solutions, both hardware and software:
Use an RC filter to eliminate the bouncing on the signal.
The switch sets the state, and a process resets it when done.
The switch sets the state, and a timer resets it.
The switch sets the state, and a second switch resets it.
Use a double throw switch. Each position sets an alternate state.
Use a double throw switch and external Set/Reset latch.
Each of these is a reasonable solution, and I have used them all at one time or another. The last two, involving the use of double
throw switches, were used in industrial control systems, where a glitch might drop a spinning blade into a pipe that was still
moving, or when a missed switch might shove that same pipe through the wall. Or the 100,000 RPM drill is in the PCB material when the table
decides to zero itself. Although I have watched all of these things happen, I was personally responsible for only one of them. I won't
say which one. All were solved by properly debouncing switches.
This schematic shows the simplest case, where the dirty switch signal is passed through to the microcontroller, which debounces the
switch by one of methods 2, 3, or 4 above. The switch is debounced, but there is no protection of the microcontroller from the
environment, which may be noisy.
Port protection
The AVR has protection diodes on each pin that will direct all over- and under-voltages to the appropriate supply rail. There is no
over-currrent protection for these diodes, though. To give them a chance, the following circuit introduces a series resistor to limit
the current.
This method still requires software debouncing, like the previous circuit, but affords a little bit of protection from externally induced
transients.
RC filter debouncing
This method uses a capacitor to filter the bounce on the line into a smooth curve. The capacitor is chosen to remove the glitches without
slowing the signal down any more than necessary. Some surge protection is offered by the resistor in series with the signal, but it is there
to limit the current from the capacitor when the button is pressed. If the capacitor is allowed to discharge "instantly" through the switch,
the peak current could be great enough that in combination with stray inductance in the circuit, a dangerously high voltage could be developed
on the pin, possibly damaging it. When choosing the capacitor value, remember that power consumption of an AVR increases considerably when
a digital input spends time in between logic states.
Like the previous two circuits, this one requires software debouncing, although not as extreme.
Double throw switch debouncing
Using a double throw switch is no different electrically, or in software, from using two SPST switches. It is very different mechanically
because it prevents the user from accidentally hitting the other switch, so in that respect it may be safer than any of the other methods.
The following circuit uses external logic to debounce the switch, and is the most reliable of the methods. You could use the R/S inputs on
a 7474 fliip-flop as well, but it won't gain you any gates or space, although it could simplify the PC board layout. The additional logic, and
board space, may be a significant issue in your design.
The AVR can communicate using USART, SPI, TWI (in some cases) but only one way is in general use - USART. The reason is that it is the one way
you can talk with any PC. How you get that serial data back and forth varies with the capabilities of the PC and the AVR circuit design. Most
newer computers do not have an available serial port. Mine has one, but it is on the motherboard, and not readily accessible. That really only
leaves USB. When you hear about USB connections to an AVR, it is almost invariably through the USART, using a USB to TTL serial converter. Most
Arduinos have the USB to TTL converter onboard, talking to the USART. Notably, the Arduino Pro and Arduino Pro Mini do not have USB on board.
If you are planning on doing any work with AVRs, and want to do it more than one or two times, it would be best to invest in a USB to TTL serial
converter from FTDI or another vendor. There are Windows device drivers available for free that will allow the USB to TTL serial converter to
look like a serial port. Linux supports it natively. Take the time to put a 6-pin 0.1 inch connector on every project, and wire it up at least
to the three required pins - transmit, receive, and ground. You can use the serial connection to upload programs, using a bootloader, on those
AVRs that support it, and it is indispensible for debugging code. Just hook up a dumb terminal program and send debug output to the serial port.
The code to do that on the AVR side is literally about 5-10 lines total, counting USART initialization.
This is kind of funny. You can buy "breakout" boards for any AVR in a dual inline package. What do you gain over a piece of single sided proto
board? You may wind up with the same number of wires and solder joints! In most cases, you still have to find a place to put a power supply, or
they provide a header for the power supply that requires a handmade cable. You can do that on a protoboard, too. In addition, you can buy AVRs
mounted on a board with a header for serial communication and a power supply connection, but you are going to pay quite a lot for them. If you
have more money than time, they are a good deal, but if you are trying to do it on the cheap, and have an extra half hour, you can do the same
as the best of them on a US$1.00 protoboard. Just my opinion. I think they are a nice solution to a problem that doesn't exist. If you are
really cheap, or in need of compactness, you can make a workable AVR circuit without any kind of board - even without a protoboard. Just solder
up the mess directly to the pins and give it all a conformal coat. I once made a stack of 32 2kx8 static RAM chips without a board, so they would
fit in the keyboard of a Commodore VIC-20. Just stacked the chips together and pulled out the chip enable pins. Not that I recommend that kind of
behavior, but cheap is cheap.
A case for a breakout board would be when using an ATmega128 or other microcontroller that is not available in a DIP package. A board like the
SchmartBoard helps make such a microcontroller useful to the average hobbyist. The Schmartboard to hold an ATmega128 is available at
Frys Electronics for around $10.00 (SchmartBoard 202-0009-02 QFP, 32-64 Pins, 0.8mm
Pitch, EZ Version).
As for a "real" development board, I think they are very handy. You don't have to wire up a switch or an LED, or a potentiometer every time you
need one because they are already on the board. You can use a switch to simulate external events, and use LEDs to simulate output. You can use
pots to simulate analog inputs. All very handy, and when you're to that point, you can build a prototype that is dedicated to the task, has no
switches or pots or LEDs, and costs a lot less. Then you reuse the development board as often as you like. There are two different designs under
"Projects" above. One is for the ATmega8 to ATmega328, and the other is for the ATmega16/32, ATmega164/324/644/1284, and ATmega8535. I don't sell
them - you download the files, have the boards made, and populate them with what you want.
