Di solito, la decisione sul microcontrollore è un equilibrio tra:

1. Funzionalità speciali (basso consumo energetico, per esempio)
2. Tempo di sviluppo.
3. Costo delle merci in produzione.

Se il breve tempo di sviluppo ha più priorità del costo delle merci, allora scegli il controller più muscoloso. È possibile eseguire l'ottimizzazione dei costi in un secondo momento come fase separata. La costoptimizzazione prematura [sic] spesso rovina i progetti.

Se sei già nella fase di ottimizzazione dei costi, inizi da un prodotto funzionante. La prima versione non ottimizzata funge da prototipo per la versione ottimizzata. La prima versione elimina i requisiti.

Correlati: Come scegliere una piattaforma MCU?

prima di iniziare a lavorare sul progetto, come facciamo a sapere quale dimensione e quanto potente microcontrollore è necessario per il progetto?

Non puoi saperlo. E questo è un grosso problema. Se scegli un microcontrollore troppo piccolo, potresti esaurire le risorse (memoria / pin / registri / altre funzionalità) e queste risorse possono essere difficili da stimare con precisione finché non è troppo tardi. Ma se scegli un microcontrollore troppo grande, stai pagando per le risorse che non stai utilizzando e questo si aggiunge al costo del sistema.

A volte puoi fare un'ipotesi plausibile su quante delle varie risorse stai l'applicazione avrà bisogno ... se ad esempio stavi eseguendo calcoli FFT, puoi calcolare la quantità esatta di memoria richiesta dai campioni. Ma è più difficile determinare in modo affidabile quanto spazio di codice oggetto richiederà il software, fino a quando non è stato scritto.

Una buona protezione contro l'esaurimento della memoria del codice è selezionare una famiglia di microcontrollori che sia scalabile su diversi punti di prezzo / prestazioni. Questo è un grande punto di forza di ARM , Microchip PIC , Atmel AVR e altri micro scalabili. Man mano che sviluppi il tuo software, puoi passare da un sistema di sviluppo più grande a un sistema di destinazione più piccolo, mantenendo basso il costo del prodotto finale.

Scalabile significa che tutti i microcontrollori di quella famiglia hanno (principalmente) lo stesso set di istruzioni e (principalmente) gli stessi registri. Quindi il software scritto per uno, funzionerà su un altro della stessa famiglia. (Il codice PIC Microchip non funzionerà su un ARM, ma se impari il PIC14 è facile passare al PIC12 o fino al PIC16.)

Se stai solo costruendo un prototipo una tantum , piuttosto che una linea di prodotti di produzione completa, la tua migliore opzione è restare con un sistema di sviluppo che è un po 'più grande di quanto pensi di aver bisogno, ma ha spazio per crescere.

Un fattore importante è la dimensione delle variabili utilizzate più spesso. Se stai utilizzando principalmente variabili a 8 bit e hai solo bisogno di accedere a porte a 8 bit, allora probabilmente puoi cavartela con un MCU a 8 bit.

Tuttavia, se hai molti 16- variabili bit e anche solo pochi 32 bit lunghi, quindi dovrai guardare un MCU a 16 bit (o anche a 32 bit) poiché l'accesso a variabili a 16 bit con un MCU a 8 bit richiede una quantità notevole di codice.

E se intendi utilizzare variabili in virgola mobile, ti consiglio caldamente un MCU a 16 o 32 bit.

Anche se non hai il tempo per scrivere gran parte del codice che dovrai usare, ti suggerisco di scriverne un po 'in anticipo e di compilare per qualunque microcontrollore tu stia usando. La maggior parte dei produttori di microcontrollori dispone di versioni gratuite dei loro compilatori, forse limitate dalla dimensione del file di output o limitando la quantità di ottimizzazione.

Idealmente, prima di progettare una nuova scheda, è necessario eseguire un progetto di prova utilizzando una scheda di sviluppo (o qualsiasi scheda disponibile in commercio) o una scheda rimanente da uno dei progetti precedenti.

Di solito, le MPU a 32 bit sono spesso più veloci a causa di una frequenza più alta, ma anche per le loro capacità o per alcuni "trucchi" che possono fare.

Come detto da @tcrosley, un MCU a 32 bit può aggiungerne due Intero a 32 bit in una volta, mentre un MCU a 8 bit dovrà utilizzare questo byte per byte. I numeri in virgola mobile richiedono almeno 16 bit e la loro matematica è più complessa, il che significa molto lavoro per l'MCU a 8 bit. Un MCU a 32 bit può fare i calcoli nell'hardware, quindi ancora una volta, in una volta sola. Uno dei trucchi potrebbe essere quello di fare quattro aggiunte di variabili a 8 bit contemporaneamente. Carica quattro valori a 8 bit nel registro e aggiungi valori a 8 bit a ciascuno di essi.

Ma non è tutto.
Dai un'occhiata anche alla periferia hardware, che non è necessariamente più potente su MCU a 32 bit!
Un'esperienza:

Nella mia università, abbiamo costruito un oscilloscopio composto da un PIC18F2550 (8 bit, 10 bit ADC, USB), un amplificatore operazionale per realizzare diversi intervalli di tensione e alcune resistenze &. Questo era inteso come un oscilloscopio molto semplice ed economico per le scuole con una frequenza di campionamento di ... immagino che fosse di circa 50 kHz. Il trasferimento è stato effettuato tramite CDC per un'elevata compatibilità.

Quando il microchip ha inventato i suoi MCU PIC32, sembrava promettente. Il prezzo era quasi lo stesso, 120M Istruzioni / s invece di 12, USB ad alta velocità invece di piena velocità. L'ultimo punto è stato interessante perché il throughput era il fattore limitante del PIC18 ei benchmark dei microchip hanno mostrato un throughput USB notevolmente superiore.

Infine, si è scoperto che il PIC18 faceva tutte le cose USB nell'hardware, mentre il PI32 sembra fare di più nel software - non appena il PIC32 ha più lavoro da fare, il throughput è diminuito. Quindi, non siamo riusciti a realizzare un oscilloscopio più veloce con PIC32.

(Non ero coinvolto in questo, quindi non conosco i dettagli)

Bene, prima di iniziare davvero a scrivere codice, devi prima fare qualche ricerca su ciò di cui avrai bisogno per realizzare un progetto. Fa parte del lavoro.

Se hai già familiarità con i microcontrollori, allora fai qualche ricerca se un UC a 8 bit è sufficiente o meno. Dipende dalla complessità, se verrà esteso o meno (come da un LCD monocromatico a un LCD a colori), è a lungo termine, deve essere un basso consumo energetico, un basso utilizzo della memoria e così via ...

Ho dovuto fare alcune ricerche su quale ARM UC dovevo scegliere e anche quale compilatore (in base al prezzo e alla popolarità). Nella mia situazione era importante verificare la disponibilità delle periferiche.

Quindi un semplice sì o no non è possibile. Quindi, benvenuto nel mondo dell'ingegneria :)

Una parola fornisce la risposta: ESPERIENZA.

Fino ad allora si provano le cose e si impara a fare esperienza.

Tieni presente anche che ci sono attività che puoi impostare su un qualsiasi MCU che potrebbero cadere a terra se viene utilizzato l'approccio di progettazione sbagliato per gli algoritmi. Molto tempo fa ho codificato il firmware per un MCU a 8 bit da 4,9 MHz che utilizzava algoritmi intelligenti ed era in grado di monitorare il ricevitore agganciato / sganciato e rilevare lo stato della suoneria filtrando il segnale di tensione della suoneria di ~ 20Hz su tutte le 28 linee telefoniche contemporaneamente e quindi segnalare tale stato a una stazione di controllo centrale per tutto il tempo che esegue un display LCD e gestisce un'interfaccia utente abbastanza complessa senza i toni DTMF rilevati. Cose divertenti.