Dal momento che sembra che tu stia sondando l'opinione, ecco il mio $ 0,02. Che stia lavorando su un ARM o AVR è importante (e quindi, mi interessa), principalmente in base a ciò che sto cercando di fare. Ci sono casi d'uso in cui un AVR ha un senso, e ci sono quelli in cui un ARM lo fa. In generale, c'è anche un compromesso tra, per esempio, AVR e PIC.
Prima di tutto, mentre probabilmente mi metterò nei guai per dirlo, il "forte contingente nella famiglia Arduino" è una specie di minoranza vocale. La maggior parte degli folk di Arduino (utenti) che ho incontrato sono quelli che preferiscono trattare il loro hardware nello stesso modo in cui tirerebbero su uno script Python per fare qualcosa di divertente, spesso con un livello inferiore di comprensione delle complessità coinvolte rispetto a loro avrebbero quando avrebbero fatto "da intorpidimento import foo". Mentre c'è un certo merito nel modo di fare le cose di Arduino, c'è anche un sacco di spazio per le critiche.
Penso che valga la pena guardare gli AVR, a parte l'ecosistema Arduino. Il contingente di Arduino ha anche tratto grande beneficio dalle ragioni che hanno reso l'AVR uno standard di fatto defacto per le cose da hobbista - un mantello che ha preso sempre più il controllo di PIC anche prima che Arduino apparisse. I concorrenti diretti dell'AVR sarebbero il PIC e, in una certa misura, l'MSP430, che sta guadagnando terreno grazie in gran parte alla forte spinta di marketing di TI combinata con i suoi strumenti di finanziamento.
Ecosistema
Come è stato menzionato in altre risposte, l'AVR è l'unica famiglia che ha un modo pulito e standardizzato per passare da zero a ciao mondo usando strumenti gratuiti. La porta avr-gcc, i pezzi che compongono la toolchain di winavr, molti schemi di programmatore con complessità e caratteristiche variabili ma ancora legati dall'autorità derivata dal supporto di avrdude rendono molto più facile che occuparsi di far funzionare la toolchain.
L'ecosistema del PIC è un incubo, con qualsiasi numero di compilatori, strumenti di programmazione, assemblatori, che cosa hai. Molti di loro non sono compatibili tra loro. Molti di loro sono pagati. Non tutti sono buoni. Ancora più importante, non esiste uno standard defacto. Le alternative free / open source (diciamo, SDCC) lasciano molto a desiderare, ma soprattutto non sono riuscite ad acquisire uno status di standard defacto come avr-gcc e company. Anche con la toolchain del software elaborata, dovresti almeno investire in un programmatore di qualche tipo. Il PICkit può costare solo 20 $ o giù di lì, ma quando devi capire come acquistarlo online (carte di credito, spedizioni internazionali, problemi del forex), può essere un affare per gli appassionati. Non c'è un buono
MSP430 è leggermente migliore, soprattutto perché è più recente (almeno in termini di popolarità) - C'è molto meno rumore con cui combattere. TI ti spedisce campioni IC con efficienza che non ho mai visto da nessun'altra parte. mspgcc è in buone condizioni e c'è persino un software di debug open source che non è difficile da trovare o configurare. Il problema, tuttavia, è che non è amico degli hobbisti come l'AVR. Hai ancora il problema del programmatore, che è più costoso di quello che dovresti acquistare per un PIC. L'operazione di fornitura a 3.3 v crea una barriera percettiva per le persone che sono abituate alla logica 5v. E non si ridimensiona in DIP - Ci sono quelli di fascia bassa disponibili, ma non una volta raggiunti i chip più raffinati.
Facilità d'uso
DIP vs SMD, penso, è una distinzione più importante di quanto spesso si pensi. Un DIP IC può essere utilizzato su breadboard, board di uso generale, qualunque cosa si chiami dove vivi e così via. Un IC SMD richiede necessariamente una corsa di fabbricazione o l'acquisto di schede adattatrici che non sono sempre facili da trovare nella dimensione o forma desiderata.
Anche la qualità del foglio dati, le note applicative e la loro leggibilità fanno la differenza. Atmel sembra fare un lavoro leggermente migliore in questo. Certo, questa è una valutazione altamente soggettiva.
Gli AVR possono usare un RC interno mentre i PIC spesso no. essi richiedono un cristallo, che rende leggermente rischiosa quando combinato con una scarsità di fiducia.
Gli AVR sembravano anche più amichevoli con la programmazione all'interno del sistema rispetto ai PIC di qualche anno fa, anche se lì avrei potuto facilmente sbagliarmi.
AVR vs ARM
La tua domanda, tuttavia, riguardava AVR vs ARM. Come ho detto all'inizio, AVR e ARM occupano spazi diversi nello spettro. Se hai qualcosa che puoi fare con un AVR, allora perché dovresti farlo con un ARM? Gli ARM sono più costosi, richiedono un numero maggiore di parti, consumano più energia, rendono il codice più complicato, richiedono processi di fabbricazione più costosi. La saldatura di un TQFP a 100 pin è più costosa della saldatura di un DIP / SOIC a 40 pin, a seconda di come si misura il costo. Questo potrebbe non valere se stai producendo in grandi volumi e usando tecniche di produzione compatibili, ma se lo stai facendo, il differenziale di prezzo diventerà ancora più avvincente per andare con la soluzione più economica.
Come controller di riferimento per l'hacking generale in casa o cosa hai, direi che AVR è più facile da usare perché: - Più standardizzato dal punto di vista dell'hobbista, più codice che posso riutilizzare da Internet perché non ce ne sono così tanti varianti del compilatore e variazioni tra nomi di registro e API tra i membri della famiglia. (Prova a trasferire il codice LPC ARM sull'hardware ATMEL ARM, vedrai cosa intendo) - Il codice diventa intrinsecamente più complicato (lo fa. Davvero). - La toolchain richiede ulteriore lavoro per l'installazione. - Interfaccia leggermente semplificata. Gli ARM generalmente ti portano a 3v3 o 1v8 Logic rendendo l'interfaccia con altri giocattoli leggermente problematica. - Più economico - Ottenere un chip ARM nel negozio di ferramenta locale non è un'opzione per me dove vivo, ottenere un AVR è.