Hay PDF para novatos de AVR.

Bueno, acabo de prender la mecha de una guerra santa en otro lado (ver sección off-topic), y para continuar, voy a avivar un poco esta.

Como lo prometido es deuda, añado un texto que escribí hace algunos días en un ratito que tuve libre en el curro sobre las diferencias que pueden encontrarse entre los micros de 8 bits habituales y los AVR. Es larga y eso que está dividida en dos posts y muy resumida, que si no daría para un documento muuuuuy largo que no tengo tiempo de escribir. Ahí va eso.

Hay varias razones por las que los AVR pueden ser tan interesantes o incluso superiores a los PIC. Dado que el tema puede ser largo, de momento sólo pondré las ventajas nimias o de escasa relevancia.
Una de los puntos interesantes de los AVR se llama Arduino. Y tiene soporte en castellano, además de ser gratuito. Arduino se basa en GCC, también gratuito, con lo que uno puede trabajar en C y ensamblador sin tener que piratear.
El GCC, llamado WinAVR, se integra perfectamente dentro del AVRStudio, también grautito, de manera que uno puede depurar su código con todas las herramientas de que dispone Atmel.
En cuanto a soporte, si uno habla inglés, difícilmente encontrará un foro dedicado a un micro que sea mejor que el AVRFreaks.net.
Hay otros compiladores que también se pueden integrar o usar desde el mismo AVRStudio, si bien el mejor de ellos, el IAR, lleva el depurador integrado, e incluso mejorado.
Aún así, el resultado de las optimizaciones y compilados en GCC es bastante bueno, estando a la altura de otros compiladores profesionales, como el CodeVision y el ImageCraft.
Hay herramientas de soporte de bajo precio, fáciles de encontrar, el AVRISP original de Atmel, con USB, cuesta unos 30€, y soporta todos los modelos de AVR (y algunos otros de Atmel no AVR).
En cuanto a distribución, si bien no hay muestras de regalo con los CornFlakes del desayuno, Farnell o Mouser tienen muchos modelos disponibles, incluso los nuevos Xmega.
Por lo que periféricos se refiere, pocas diferencias hay entre los micros de la mayoría de fabricantes, si bien los Xmega, desde primavera del 08, tienen ciertos periféricos que pueden ser relevantes y que de momento no tiene Microchip.
Los patillajes disponibles son más variados aún que los periféricos, y en la mayoría de casos, hay disponibles varios modelos pin compatibles, de manera que uno puede empezar con el 'hermano pequeño' (como el ATmega16) y acabar con el 'hermano mayor' si hace falta (como el ATmega1284).
Eso incluye varios micros interesantes en formato DIP40 (como los anteriormente mencionados), e incluso en TQFP100, BGA, etc.

Si vamos directo a las 'prestaciones', debemos empezar por los MIPS. Mentiras Idioteces Paparruchas y Sandeces. Es en teoría la 'velocidad' de proceso del micro. Cuesta abajo con el viento a favor y con las orejas desplegadas.
MIPS es en realidad una mentira para cualquier micro. En realidad, lo que los vendedores nos están dando es la cantidad de ciclos de máquina por segundo que un micro es capaz de realizar.
Pero la mayoría de micros, en este aspecto PIC, AVR y ARM son iguales, tienen instrucciones que necesitan más de un ciclo de máquina. Por eso, en realidad, los MIPS reales siempre están por debajo del valor anunciado.
En este aspecto, los PIC y lo AVR se parecen mucho: el pipeline de dos etapas hace que muchas instrucciones se ejecuten en dos ciclos de máquina, por aquello de vaciar la pila del PipeLine. La única diferencia, es que un PIC necesita cuatro ciclos de reloj para cada ciclo máquina, mientras que los AVR sólo necesitan uno.
Puede parecer irrelevante, pero si uno intenta comercializar algo en los USA, el hecho de que una señal o reloj del sistema esté por encima de los 25MHz implica pasar la FCC. Así pues, los AVR a 20 'MIPS' no necesitan pasar dicha homologación, mientras que los PIC necesitan 80MHz para 'correr' lo mismo, y por tanto, estan sujetos a normativa.
Los AVR habitualmente tienen 16 o 20 MHz a 5V, y 8, 10 y 32 MHz a 3V3. Microchip suele estar por debajo o igual.
De todas maneras, los MIPS no lo son todo, y menos aún si uno programa en C. Al fin y al cabo, el C es una gruesa alfombra bajo la cual los fabricantes de micros barren la suciedad (y algunos milagros).
En este aspecto, los puntos relevantes e importante de los AVR son en realidad una diferencia, en igualdad de MIPS, pero eso, será próximamente.
Otro aspecto interesante es que todos los AVR tienen un subconjunto (grande, unos 120) de instrucciones que es el mismo en toda la familia, desde los viejos AT90S a los nuevos Xmega. Las únicas variaciones son para acomodar los nuevos modelos de memoria, de más de 128KB de Flash y hasta 16MB (extenos) de RAM.
Quizás haga falta añadir algún otro punto a lo anteriormente expuesto, como los multiplicadores o unidades de multiplicación-acumulación, que casi todos los micros tienen. Hay algunas diferencias, a veces a favor de los PIC, a veces a favor de otros, a veces a favor de los AVR.
En general, de todos los puntos anteriormente explicados, muy dependientes del datasheet, ninguno es realmente decisivo para elegir una arquitectura en frente a la otra. Algunos puntos son muy favorables a un micro y a determinadas circunstancias, pero bajo otras circunstancias, todo cambia.

Y ahí va el segundo. Espero no ser indigesto.

Sin embargo, hay varios puntos importantes que sí marcan una diferencia entre los micros que pueden ser cruciales, pero como es un tema largo (y eso que no he entrado en ningún detalle), lo dejo para otro post, que ya soy muy cansino.

Los principales motivos por los cuales he adoptado a los AVR como los micros de mi elección en el sector de los 8 bits son los siguientes:
- RAM sin bancos (que levanten la mano los usuarios de lo PIC que odien la RAM en bancos), lineal, y con su propio rango de direcciones (la arquitectura de Freescale tiene un único rango de direcciones para RAM, FLASH y SFR's).
- Stack lineal. Los PIC tienen un stack fijo Hardware. En sus tiempos (más o menos cuando yo nací, por allá de 71) eso era ventajoso: era mucho más rápido que la RAM. Casi cuarenta años más tarde, eso ya no es cierto. Así que los AVR (como los 8051 y otros), tienen el stack en RAM, mucho menos limitado.
- Multiacumulador. El principal motivo que me hizo probar los AVR. Su principal arma y ventaja. Un estilo de arquitectura que se usaba antes de los AVR sólo en los microprocesadores grandes, y que hasta Microchip ha adoptado para todos sus micros de más de 8 bits. El AVR es el único de 8 bits que yo conozca que tenga dicha prestación.

Pero ¿porqué es una ventaja esto último? La respuesta es difícil de explicar, pero espero que con un ejemplo, todos los que hayan programado PICs en ensamblador la entiendan.
Una de las estructuras habituales en un programa es el bucle con contador, tipo For (...;...;...) en C. En un micro con un único acumulador o registro de trabajo, eso implica que en una posición de RAM se debe almacenar el contado, cargarlo al W, incrementarlo (o decrementarlo), valorar si ha finalizado, guardarlo en la RAM, ejecutar lo que sea dentro del bucle, y repetir.
Esto implica para cada bucle una lectura de RAM y una escritura a la misma, como mínimo. Dos instrucciones que uno se ahorra si tiene otro registro acumulador o de trabajo donde almacenar dicho contador. Es decir, que si algunas variables locales se pueden guardar en registros internos, no sólo nos ahorramos RAM si no también ciclos de reloj en instrucciones que no hacen falta, ni memoria Flash para las mismas.
Por eso, el AVR con 32 registros acumuladores permite tener varias variables locales en los mismos, como los contadores del bucle, de manera que no hace falta ir guardando ni escribiendo en la RAM. Pero también facilita el trabaja con variables de más de 8 bits, simplemente concatenando varios de estos registros. Así, en las operaciones de 16 bits, el número de instrucciones necesarias para hacer una suma u otra operación se reducen drásticamente.
De esta manera, al necesitar menos trasiego de datos, accesos al bus, menos instrucciones y menos ciclos de reloj para hacer la misma tarea, resulta que con los mismos MIPS, los AVR son capaces de realizar más cosas más rapidamente que cualquier otro sistema con un sólo acumulador (eso incluye a muchos fabricantes).
Para acabar, los Xmega han introducido un par de periféricos muy interesantes: un conversor ADC de 12 bits a 1 millón de muestras por segundo, y un controlador de DMA. Como los Xmega1281A1 que tengo encima de la mesa tienen dos de estos conversores dentro, éstos son capaces de generar 4MB de datos por segundo. El simple hecho de copiar estos datos a la RAM interna ya es una afrenta a los 32MIPS de que son capaces. Por eso, llevan DMA.
Comento esto del DMA, porque tal y como había dicho antes, los MIPS son siempre relativos, y no es oro todo lo que reluce. Si la arquitectura de los AVR ya les da ventaja a igualdad de MIPS, el DMA es aún una mejora importantísima cuando se trata de comunicaciones o de mover grandes cantidades de datos. De hecho, los Xmega pueden copiar los 4MB de datos por segundo directamente a memoria con la CPU totalmente parada. El DMA también se puede aplicar a los puertos serie, SPI, DAC, etc.
Si a este conjunto de prestaciones le añadimos que el micro es tan fácil de usar como los PIC, resulta que tenemos un micro que en muchos casos tiene las mismas prestaciones que un micro de 16 bits (como los de TI o de Maxim/Dallas), con las ventajas de los 8 bits. Y por eso, cuando los AVR se empiezan a quedar cortos, la mejor salida es ir a por un micro de 32 bits, que por desgracia no son tan sencillos, aunque esto está cambiando, y si tenemos en cuenta el precio...

Para acabar, me gustaría relanzar un reto que hice hace mucho tiempo que sirve perfectamente para ilustrar las diferencias entre los PIC y los AVR. Se trata de escribir un programa en ensamblador del PIC, y compararlo con el código equivalente del AVR. Yo pongo el código del AVR, una suma de 256 bytes de datos de la RAM, con posterior división por 4, y reto a cualquier programador de PIC a que consiga hacerlo con su microchip, en ensamblador, en menos ciclos de máquina e instrucciones. ¿Alguen se apunta?

Muy bueno el comentario. Aún así, la gente tiende a aprender PIC o centrarse en él más que los AVR, aunque los AVR sean mejor.

Más bien diría que los profesores tienden a enseñar PIC más que cualquier otro. Hay varias razones, al menos según me han comentado varios de estos profesores:

- Los PIC son muy sencillos de aprender a programar en ensamblador. Pocas instrucciones, pocos periféricos (enseñan el 16F84, que conste que sé que tienen muuuuchas cosas más), y rápido de aprender en pocos meses para los que no tienen ni papa. Al César lo que es del César. Cuando llevas 10000 líneas de ensamblador con MOVW y similares a porrones, y te pasas a los AVR, enseguida te sientes más cómodo. Claro que ahora yo programo en C.

- Ciertos señores en España han hecho muy bien su trabajo, regalando todo lo necesario para programar los PIC a las universidades, sin nisiquiera pedírselo. Justo al revés que los señores de Mototrola-Frescales, que básicamente tenías que concertar audiencia. Siempre he mantenido que la estrategia de márketing de Microchip es de las mejores, ya que entre esta política de regalar a las universidades, y luego muestras gratuitas a los aficionados, seguro que tiene éxito. Aún así, no fueron los primeros. Yo personalmente recibí copias 'piratas' de ciertos programas que ahora se usan muy mucho en la electrónica, para que las pasase a mis compañeros de la universidad.

Una vez que uno se ha acostumbrado a unas herramientas, llámese PIC o AVR, o ARM, etc, lo cómodo es no cambiar. Pero yo soy un bicho raro y siempre me gusta hacer cosas nuevas (ahora estoy trabajando en un desarrollo con ARM STM32 Cortex M3 para el trabajo).

Aún así, para muchas cosas, los PIC y los AVR van más que sobrados, y usar uno u otro, es más cuestión de usar lo que uno ya conoce que de perder el tiempo en aprender.