Questo è uno di quei temi che possono essere molto dibattuti. Ci sono molti punti di vista diversi e cose diverse sono importanti per persone diverse. Cercherò di dare una risposta completa, ma capisco che ci sarà sempre qualcuno che non è d'accordo. Basta capire che quelli che non sono d'accordo con me hanno torto. (Stavo solo scherzando.)
Riepilogo rapido:
Questa risposta sarà lunga, quindi lasciatemi riassumere in anticipo. Per la stragrande maggioranza delle persone, l'ultimo raccolto di chip ARM Cortex-M0 / M3 / M4 offre la migliore soluzione, le migliori caratteristiche per il costo. Questo è vero anche quando si confrontano questi MCU a 32 bit con i loro antenati a 8 e 16 bit come PIC e MSP430. Gli M0 possono essere acquistati per meno di US $ 1 / ciascuno e gli M4 per meno di US $ 2 / ciascuno, quindi ad eccezione delle applicazioni molto sensibili al prezzo, le soluzioni ARM sono molto carine. Gli M0 hanno una potenza molto bassa e dovrebbero essere abbastanza buoni per la maggior parte delle persone. Per coloro che sono molto sensibili alla potenza, MSP430 potrebbe essere comunque una scelta migliore, ma vale la pena prendere in considerazione gli M0 anche per queste applicazioni.
Se sei interessato ad un'analisi più approfondita, continua a leggere, altrimenti puoi smettere di leggere ora.
Esaminerò ora ciascuna area e confronterò i diversi MCU:
Velocità di esecuzione
Naturalmente le MCU a 32 bit saranno più veloci. Tendono ad avere una velocità di clock maggiore, ma fanno anche più lavoro per ciascuno di questi orologi. MCU come ARM Cortex-M4 includono istruzioni di elaborazione DSP e possono persino avere supporto in virgola mobile nell'hardware. Le CPU a 8 e 16 bit possono funzionare su numeri a 32 bit, ma non è efficiente nel farlo. In questo modo si consumano rapidamente i registri della CPU, i cicli di clock della CPU e la memoria flash per l'archiviazione del programma.
Facilità di sviluppo
Secondo me, questa è la ragione più preziosa per l'utilizzo dei moderni MCU a 32 bit, ma anche la più sottovalutata. Vorrei prima confrontare questo con i PIC a 8 bit. Questo è il confronto del caso peggiore, ma anche il migliore per illustrare i miei punti.
I PIC più piccoli richiedono sostanzialmente che la programmazione sia eseguita in linguaggio assembly. È vero, ci sono compilatori C disponibili anche per i PIC a 8 bit, ma questi compilatori sono gratuiti o buoni. Non è possibile ottenere un compilatore valido e gratuito. La versione gratuita del compilatore è paralizzata dal fatto che la sua ottimizzazione non è buona come la versione "Pro". La versione Pro costa circa $ 1.000 e supporta solo una famiglia di chip PIC (chip da 8, 16 o 32 bit). Se si desidera utilizzare più di una famiglia, è necessario acquistare un'altra copia per altri $ 1.000. La versione "Standard" del compilatore offre un livello medio di ottimizzazione e costa circa $ 500 per ogni famiglia di chip. I PIC a 8 bit sono lenti per gli standard moderni e richiedono una buona ottimizzazione.
In confronto, ci sono molti buoni compilatori C per ARM MCU che sono gratuiti. In presenza di limitazioni, tali limiti sono in genere relativi alla dimensione massima della memoria flash supportata. Sugli strumenti di Freescale Codewarrior questo limite è di 128 KB. Questo è molto per la maggior parte delle persone su questo forum.
Il vantaggio di usare un compilatore C è che non devi preoccuparti (tanto) con i dettagli di basso livello della mappa di memoria della CPU. Il paging sul PIC è particolarmente doloroso ed è meglio evitarlo se possibile. Un altro vantaggio è che non devi preoccuparti del disordine di consegnare numeri a 16 e 32 bit su una MCU a 8 bit (o numeri a 32 bit su una MCU a 16 bit). Anche se non è molto difficile farlo nel linguaggio assembly, è un dolore nella parte posteriore ed è soggetto a errori.
Esistono altri compilatori non ARM C che funzionano bene. Il compilatore MSP430 sembra fare un lavoro ragionevole. Gli strumenti Cypress PSoC (in particolare PSoC1) sono difettosi.
Modello di memoria piatta
Un MCU che ha paginato RAM / registri / Flash è semplicemente stupido. Sì, sto parlando dei PIC a 8 bit. Stupido, stupido, stupido. Questo mi ha spento così tanto dai PIC che non mi sono nemmeno preso la briga di guardare le loro novità. (Dichiarazione di non responsabilità: ciò significa che i nuovi PIC potrebbero essere migliorati e io proprio non lo so.)
Con una MCU a 8 bit è difficile (ma non impossibile) accedere a strutture di dati superiori a 256 byte. Con una MCU a 16 bit che viene aumentata a 64 kbyte o parole chiave. Con MCU a 32 bit che arriva fino a 4 gigabyte.
Un buon compilatore C può nascondere molto al programmatore (aka You), ma anche in questo caso influisce sulla dimensione del programma e sulla velocità di esecuzione.
Ci sono molte applicazioni MCU per cui questo non sarà un problema, ma ovviamente ce ne sono molte altre che avranno problemi con questo. È principalmente un problema di quanti dati sono necessari (array e strutture) in RAM o Flash. Naturalmente, all'aumentare della velocità della CPU aumenta anche la probabilità di utilizzare strutture di dati più grandi!
Dimensione del pacchetto
Alcuni PIC piccoli e altri MCU a 8 bit sono disponibili in pacchetti davvero piccoli. 6 e 8 pin! Attualmente il più piccolo ARM Cortex-M0 che conosco è in un QFN-28. Mentre un QFN-28 è abbastanza piccolo per la maggior parte, non è abbastanza piccolo per tutti.
Costo
Il PIC più economico è circa un terzo del prezzo del ARM Cortex-M0 più economico. Ma questo è davvero US $ 0,32 contro US $ 0,85. Sì, quella differenza di prezzo conta per alcuni. Ma credo che la maggior parte delle persone su questo sito Web non si preoccupi di quella piccola differenza di costo.
Allo stesso modo, quando si confrontano MCU più capaci con ARM Cortex-M0 / M3 / M4 di solito ARM Cortex esce "all'incirca uniforme" o in cima. Quando si tiene conto delle altre cose (facilità di sviluppo, costi del compilatore, ecc., Gli ARM sono molto interessanti.
Secondo riassunto
Immagino che la vera domanda sia: perché NON dovresti usare un ARM Cortex-M0 / M3 / M4? Quando il costo assoluto è estremamente importante. Quando il consumo di energia estremamente basso è critico. Quando è richiesto il pacchetto più piccolo. Quando la velocità non è importante. Ma per la stragrande maggioranza delle applicazioni nessuna di queste si applica e l'ARM è attualmente la soluzione migliore.
Dato il basso costo, a meno che non ci sia una buona ragione per non usare un ARM Cortex, allora ha senso usarne uno. Consentirà tempi di sviluppo più rapidi e semplici con meno mal di testa e margini di progettazione più ampi rispetto alla maggior parte degli altri MCU.
Sono disponibili altri MCU Cortex a 32 bit non ARM, ma non vedo alcun vantaggio. Ci sono molti vantaggi nell'utilizzo di un'architettura CPU standard, inclusi migliori strumenti di sviluppo e una più rapida innovazione della tecnologia.
Certo, le cose possono e cambiano. Quello che dico è valido oggi, ma potrebbe non essere valido tra un anno o addirittura un mese da adesso. Fai i tuoi compiti.