Just a FYI, the author of this tutorial got ousted out of AVRFreaks for bad behavior and plagiarism (especially tutorial plagiarism!). [0] Another tutorial of his had several errors. [1] I would personally recommend either [2] or [3] as a beginner's tutorial for AVR assembly and [4] for all your other questions.

[0] http://www.avrfreaks.net/index.php?name=PNphpBB2&file=vi...

[1] http://www.reddit.com/r/programming/comments/aqkt2/dirty_mat...

[2] http://www.avr-asm-tutorial.net/avr_en/beginner/index.html

[3] http://www.avrbeginners.net/

[4] http://www.avrfreaks.net/index.php?name=PNphpBB2&file=in...

Thanks, I wasn't aware of that. I've read through parts of [2] and [3] before and certainly found them to be of help.

AVR assembly is one of my favorites. Compared to 6502, Z80, and x86, there is a relative plethora of registers (32 of them!) and, if your application is simple enough, you can write code that doesn't use any RAM at all. In fact, some of the smaller AVRs don't have any RAM aside from the registers.

The instruction set is organized quite nicely and most non-memory instructions (even the multiply instructions) take one cycle. Ah, the joys of RISC.

It's a nice ISA but has some painful aspects. 8-bit registers aren't big enough for many purposes. Shift instructions are one bit position at a time. Explicit stack pointer manipulation isn't atomic.

The best thing about AVR is avr-gcc.

avr-gcc and avr-libc are really great but I'm working with the ATTiny4 right now and I can't seem to get a working gcc toolchain for it (not to mention it only has 512 bytes of flash and 32 bytes of SRAM). I did spend a decent amount of time trying to getting avr-gcc and avr-libc working with these MCUs but I've ended up just falling back to ASM.

The best thing about AVR is the stack - and that's why you don't really need the ASM.

AVR is the cheapest kit that fully support the GCC toolchain. It comes with its own stripped-down glibc, and installs a GCC cross-compiler and is amazing for that reason alone.

Also worth a look are the ARM Cortex-M3 chips. They're competitive with AVR in the $3-10 range, have even better tool support, and are much more powerful.

This is really great!

Lots of people are saying that you can just use avr-gcc. Which is technically true, but it still requires knowledge and bitwise manipulation of AVR registers.

For example, you can't really use timers without understanding the time-related registers and interrupts, so the C code for managing that looks almost identical to the assembly. Nice to have a guide that goes through those register operations line-by-line so I can understand what is happening.

Awesome!

To the author of this page, you should consider spelling out the meaning of AVR somewhere near the top of the page, so readers don't have to Google it. Also tell us a bit more about what it is before launching into an introduction that seems to assume we already know.

>Practically all languages convert their programs to assembly because assembly is close to what the hardware understands

It has been a long time since I did any sort of dabbling/reading in the area but is that even true? Afaik very few languages that compile to executable machine code 'convert their programs to assembly'. They go directly from their internal AST/DFG/CFG representation to machine code, an intermediary stop at the ASM level would be unnecessary no?

Many compilers can nonetheless output assembly, if just for debugging purposes.