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.
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.
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.
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 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.
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.
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!
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.
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.
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)|
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.
"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
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 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.
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.
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.
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:
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.
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.
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:
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.
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.
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.
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.