Já que você parece estar pesquisando opiniões, aqui estão meus US $ 0,02. Se eu estou trabalhando em um ARM ou AVR importa (e, portanto, eu me importo), principalmente com base no que estou tentando fazer. Há casos de uso em que um AVR faz sentido e outros quando um ARM faz. Em geral, também existe uma troca entre, digamos, AVR e PIC.
Primeiro, embora eu provavelmente tenha problemas por dizer isso, o "forte contingente da família Arduino" é uma minoria vocal. A maioria dos usuários de arduino que encontrei são do tipo que prefere tratar seu hardware da mesma maneira que cria um script python para fazer algo divertido, geralmente com um nível mais baixo de compreensão dos meandros envolvidos do que eles teria quando faria "from numpy import foo". Embora exista algum mérito na maneira de fazer as coisas no Arduino, também há muito espaço para críticas.
Eu acho que vale a pena olhar para os AVRs, além do ecossistema do Arduino. O contingente do Arduino também se beneficiou bastante das razões que tornaram o AVR um padrão defacto para coisas amadores - um manto que vem substituindo cada vez mais o PIC, mesmo antes de o arduino aparecer. Os concorrentes diretos do AVR seriam o PIC e, até certo ponto, o MSP430, que está ganhando força devido em grande parte ao forte impulso de marketing da TI combinado com suas ferramentas de subsídio.
Ecossistema
Como já foi mencionado em outras respostas, o AVR é a única família que possui uma maneira limpa e padronizada de ir do zero ao olá mundo usando ferramentas gratuitas. A porta avr-gcc, as peças que compõem a cadeia de ferramentas winavr, muitos esquemas de programadores com complexidade e recursos variados, mas ainda vinculados pela autoridade derivada de serem suportados pelo avrdude, tornam muito mais fácil do que lidar com a implementação da cadeia de ferramentas.
O ecossistema do PIC é um pesadelo, com vários compiladores, ferramentas de programação, montadores, o que você tem. Muitos deles não são compatíveis entre si. A maioria deles é paga. Nem todos eles são bons. Mais importante, não há um padrão defacto. As alternativas de código aberto / gratuito (digamos, SDCC) deixam muito a desejar, mas mais do que isso não conseguiu obter um status de padrão defacto como o avr-gcc e a empresa. Mesmo com a cadeia de ferramentas de software elaborada, você teria pelo menos que investir em algum programador. O PICkit pode custar apenas US $ 20, mais ou menos, mas quando você precisa descobrir como comprá-lo on-line (cartões de crédito, remessa internacional, aborrecimentos cambiais), pode ser um rompimento de acordos para entusiastas. Não há um bom,
O MSP430 é marginalmente melhor, principalmente por ser mais novo (pelo menos em termos de popularidade) - há muito menos barulho para enfrentar. A TI envia amostras de IC para você com eficiência que nunca vi em nenhum outro lugar. O mspgcc está em boa forma e existe até um software de depuração de código aberto que não é difícil de encontrar ou configurar. O problema, porém, é que não é tão amigável para os entusiastas quanto o AVR. Você ainda tem o problema do programador, que é mais caro do que o necessário para comprar um PIC. A operação de fornecimento de 3,3v coloca uma barreira percebida para as pessoas que estão acostumadas ao 5v Logic. E não é escalável no DIP - existem os mais baratos disponíveis, mas não quando você alcança os chips mais detalhados.
Fácil de usar
DIP vs SMD, eu acho, é uma distinção mais importante do que costuma ser creditada. Um IC DIP pode ser usado na tábua de pão, placas de uso geral, como são chamadas onde você mora e assim por diante. Um IC SMD requer necessariamente uma execução de fabricação ou compra de placas adaptadoras que nem sempre são fáceis de encontrar no tamanho ou formato que você deseja.
A qualidade da folha de dados, as notas de aplicação e a legibilidade delas também fazem a diferença. Atmel parece fazer um trabalho marginalmente melhor nisso. Obviamente, essa é uma avaliação altamente subjetiva.
Os AVRs podem usar um RC interno, enquanto os PICs geralmente não. Eles exigem um cristal, o que o torna um pouco arriscado quando combinado com uma escassez de confiança.
Os AVRs também pareciam mais amigáveis com a programação no sistema em comparação com os PICs há alguns anos atrás, embora eu pudesse facilmente estar errado lá.
AVR vs ARM
Sua pergunta, no entanto, tinha a ver com AVR vs ARM. Como eu disse no início, AVR e ARM ocupam diferentes espaços no espectro. Se você tem algo que pode fazer com um AVR, por que deseja fazê-lo com um ARM? Os ARMs são mais caros, exigem maior número de peças, consomem mais energia, resultam em códigos mais complicados, precisam de processos de fabricação mais caros. Soldar um TQFP de 100 pinos é mais caro do que soldar um DIP / SOIC de 40 pinos, dependendo de como você mede o custo. Isso pode não ser válido se você estiver produzindo grandes volumes e usando técnicas de produção compatíveis com isso, mas se estiver fazendo isso, o diferencial de preço será ainda mais atraente para a solução mais barata.
Como um controlador obrigatório para hackers em geral ou o que você tem, eu diria que o AVR é mais fácil de usar porque: - Mais padronizado de uma perspectiva amadora, mais código posso reutilizar da Internet, porque não há muitos variações do compilador e variações entre nomes de registro e API entre membros da família. (Tente portar o código LPC ARM para o hardware ATMEL ARM, você verá o que eu quero dizer) - O código se torna inerentemente mais complicado (realmente.) - A cadeia de ferramentas exige trabalho adicional para configurar. - Torna a interface um pouco mais fácil. Em geral, os ARMs reduzem a lógica 3v3 ou 1v8, tornando a interface com outros brinquedos um pouco problemática. - Mais barato - Conseguir um chip ARM na loja de hardware local não é uma opção para mim onde moro, é um AVR.