• AtmelAVR

Atmel AVR

Atmel is the manufacturer of the AVR series of microcontrollers, along with programmable logic devices and other products. Aside from the manufacturer's web site, AVRFreaks is a good source of information for AVR's, including a side-by-side comparison chart of AVR devices.

In addition to the information on this page, this document has a very good introduction to AVR's and includes many links to additional resources (and free code!)

Development Tools

• AVR Studio is Atmel's free integrated development environment for all of their microcontrollers. It includes an assembler, linker, simulator, and interface to the STK500 development system/programmer. You can get AVR Studio 4 from this local copy [72MB] (version 4.13 build 528). Make sure to check for additional service packs.

• AVRGCC is a port of the free GCC compiler/assembler/debugger suite to the AVR. It is available as source code and as precompiled binaries for lots of systems, including WinAVR for Windows systems.

• You can compile the AVR-GCC toolchain yourself by following the instructions in the AVR-LIBC documentation. NOTE: Binutils 2.17 uses '-mmcu=atmega324' for the ATmega324P while GCC uses 'atmega324p'. This leads to a broken toolchain. Prior to compiling the binutils, change 'atmega324' to 'atmega324p' in the gas/config/tc-avr.c file.

• SimulAVR is another AVR simulator. SimulAVR is capable of serving as a back-end to the GDB simulator (part of AVRGCC) and supports source-level debugging.

• AVRDUDE is an uploader/downloader for a variety of AVR programming systems, including the STK500. AVRDUDE comes with source and can be used on Linux systems to download programs to the STK500 without having to run AVR Studio from Windows.

• AVROSP is an Atmel-supported open source programmer for the AVR.

• EGR 345 is an engineering course that involves substantial programming of Atmel Mega32 microcontrollers for systems control.

Software

• Lots of software projects (complete applications, libraries, etc.) are available at AVRFreaks

• Peter Fleury has some libraries that look very useful: a UART library, HD44780 LCD library, and an I2C (TWI) master interface library

• PFAVR is a free implementation of Forth for the ATmega64 and ATmega128 processors. Forth allows you to quickly and interactively develop expertise with the system hardware (although you do have to learn Forth!)

• MegaLoad is a self-programming bootloader that, once programmed into the boot sector of FLASH, allows you to reprogram your AVR through a serial port (i.e., without an AVRISP/STK500, although you will need such a programmer to program MegaLoad the first time).

  • You can get a command-line Python loader for Linux called pygaload that can be used instead of MegaLoad (since, of course, MegaLoad does not run on Linux systems).

  • The HEX files have different names depending upon the target AVR, which UART to use, and whether a high-speed (>= 8 MHz) or low-speed (< 8 MHz) clock is being used. For example, 'm128_0_h.hex' is for the ATmega128, UART 0, high-speed clock.

  • All HEX files have been compiled to use a 512-byte boot section. You MUST program the device fuses to reflect this boot section size.
  • The HEX files support programming FLASH only, not EEPROM nor lock bits. They are also set up for auto-baud mode.

  • MegaLoad keeps changing the bootloader interface protocol. The bootloaders work with version 5 and 6.1.

  • Of course, real engineers compile their own HEX files. MegaLoad comes with source code for the IAR compiler. You can:

    • Download a time-limited trial version of the IAR compiler from ImageCraft and compile the HEX files.

    • Use ports of the bootloader (AVR code only, not the Windows client) to AVR-GCC. Here is one and another.

Data Sheets

Please DO NOT print these out (on PSE printers) as they are very long and will waste a lot of paper. Get used to reading PDF files on the screen and using the PDF navigation resources to move around quickly.

• ATmega32

• ATmega324P

• The AVR Instruction Set

Silly Bug List -- Hardware/Assembly

Here is a list of gotchas that might save you some headaches. This list is for hardware and assembly language issues. For AVRGCC issues, see below.

• See the AVR-LIBC FAQ for a good list of gotchas to watch out for.

• The ATmega128 comes with the ATmega103 compatibility mode turned on! You have to disable this with a fuse.
• Similarly, make sure you program your fuses carefully before you program your chip for the first time. For example, if JTAG is enabled (and it usually is by default), you will not be able to use some port pins as digital I/O.
• The ATmega128 (and other AVR's!) does not use the MOSI/MISO SPI pins for in-circuit serial programming. It uses Port E bits 0 and 1, which are also the UART0 TXD/RXD pins. Either use UART1 or design carefully.

• The AVR instruction cycle frequency is the same as the oscillator frequency. It is not divided by 4 as in the MicrochipPIC or other processors. Note, however, that there are several non-single-cycle instructions.

• To read an I/O port, use the PINx register not the PORTx register. The PORTx register can be read but returns the last value written to it, which is useless if the port pin is configured as an input. The PINx register returns the actual voltage values at the port pins.
• I/O pins configured as inputs have a 2-clock-cycle delay from voltage change to a visible change in the PINx register due to a hardware synchronizer (read the datasheet section on "I/O Ports"). This is a very important consideration when implementing, for example, three-wire interfaces in which you generate a clock signal and shift in data from a device one bit at a time. The following sequence of instructions may not work:

         PORTB |= _BV(5);       // Set CLK high
         data |= PINB & _BV(2); // Read MISO

• You must introduce some delay between the output clock and reading the input register. The second line above will only read the value of Port B pin 2 from 2 cycles before the instruction, which is before the event of setting the output clock high.

• Pullups on I/O pins are enabled by configuring the pin as an input and writing a 1 to the corresponding PORTx register pin.
• Pullups should be disabled on A/D pins for maximum accuracy.

• I/O ports with locations above 0x40 (64) must be written to as RAM locations using LDS/STS but with an offset of 0x20 (32). I/O ports with locations below 0x40 (64) may be written either as RAM (with an offset) or with IN/OUT (without offset).

• The CBI/SBI instructions only work on "low" I/O locations (depends on the chip). Not all I/O ports are accessible with CBI/SBI.

• AVR's are similar but not necessarily identical. For example, the Timer 0 peripherals on the ATmega16 and ATmega128 are very similar, but the prescale settings are subtly different. Do not assume that peripheral code ports cleanly from one AVR to another.
• AVR's are subtly different in pin usage, too. For example, the ATmega chips have pull-up resistors on the RESET line but the ATtiny chips do not (in general...check carefully!)
• If using a pin as a general I/O pin, make sure a) your chip supports the pin in the direction (input/output) that you want it to, since some chips have dedicated input-only or open-collector output pins, and b) any peripheral is not overriding the general I/O pin function (for example, the ATtiny12 has its comparator function turned on by default)

Silly Bug List -- AVRGCC

These gotchas are specific to the AVRGCC development tools.

• Note that starting with AVR-LIBC version 1.4, the method of declaring ISR's is by using the ISR() notation instead of SIGNAL(), and you must #include <avr/interrupt.h>, as <avr/signal.h> has gone away. Also, the ISR vector names have also changed. Read the documentation for your version of AVR-LIBC carefully.

• The parameter to ISR() must be exactly correct. Check carefully against the header include file, or better yet, the assembly code. If it is not correct, you will receive NO WARNING! Instead, your program will magically "reboot" as uninitialized interrupt vectors are the same as the reset vector.

• The macros for bit names (e.g., DDRD7, PE2) are bit numbers, they are not bit masks. Thus, "PORTD |= PD3" is incorrect. The correct way to set bit 3 is "PORTD |= _BV(PD3)".