Qual è il posto dei microcontrollori a 8 e 16 bit? Perché non è subentrato a 32 bit?

Qual è il vero limite in termini di compromesso tra costo e prestazioni per la selezione di microcontrollori a 32 bit?

In altre parole, con l'ascesa e il dominio delle architetture ARM, perché stiamo ancora usando microcontrollori a 8 e 16 bit? Sono ancora molto più economici?

Comprendo che i dispositivi di fascia bassa non necessitano delle risorse offerte da architetture più grandi e complesse. Tuttavia, qual è la vera motivazione per usarli ancora se i costi sembrano convergere verso lo stesso intervallo?

Forse un anno fa, c'era una differenza significativa tra i microcontrollori di fascia bassa a 8 bit e i più economici a 32 bit. Non è più il caso.

Sulla base dei prezzi all'ingrosso di Digi-Key, è possibile ottenere un PIC10F200 a 8 bit per 35ȼ in 2500 quantità in un pacchetto SOT-23-6. Ottieni un CY8C4013SXI-400 a 32 bit (ARM Cortex-M0) per 36ȼ in 2500 quantità in un pacchetto SOIC-8. (I prezzi all'ingrosso di Digi-Key non sono realistici in termini di ciò che i produttori pagano effettivamente, il che è probabilmente molto meno, ma penso che sia valido da usare per un confronto approssimativo dei prezzi tra prodotti diversi per quantità simili.)

Quindi l'OP ha ragione, stanno convergendo.

Quindi perché i chip a 32 bit non vengono utilizzati di più? Bene, come ho detto nel mio primo paragrafo, questa parità di prezzo e dimensioni è avvenuta solo nell'ultimo anno o 18 mesi. E hanno ancora ottenuto un lungo strada da fare prima ci sono abbastanza chips per essere competitivi.

Dei 6875 chip ARM disponibili da Digi-Key, ce ne sono solo quattro in stock con prezzi quantitativi inferiori a un dollaro. Quattro . Nel frattempo ci sono centinaia di chip a 8 bit sotto un dollaro per gli ingegneri tra cui scegliere.

Ma supponiamo che fossero disponibili almeno una dozzina di micro a 32 bit di fascia bassa. Verranno automaticamente raccolti su quelli a 8 bit?

Prima di tutto devi informare gli ingegneri di loro. C'è sempre molta resistenza al cambiamento. Nuove cose da imparare: dal punto di vista hardware, imparare a incorporare il nuovo chip in un circuito. Ci sono nuovi strumenti, come programmatori in-circuit, nuovi compilatori, ecc. Per gli ingegneri del firmware, imparare come usare un nuovo set di periferiche e timer (principalmente layout di registri e significati di bit).

32 bit è bello e tutto il resto, ma a meno che non si debba fare un calcolo pesante, qual è il punto? Se hai solo quattro pin GPIO, accedervi internamente come un registro a 32 bit non offre alcun vantaggio rispetto all'utilizzo di un registro a 8 bit.

Penso che il consumo energetico sarà sempre a favore dei micro a 8 bit.

Ad esempio, PIC10F200 assorbe 175 µA in esecuzione a 4 MHz e 2v e 100 nA in modalità sospensione. Il CY8C4013SXI-400 assorbe circa 800 µA in esecuzione a 4MHz e 2v e 1 uA in modalità sleep. (Il foglio dati per CY8C4013SXI non aveva numeri per 4 MHz o 2v, quindi ho dovuto fare delle stime - il foglio dati dice che disegna 2 ma @ 6 MHz e 3.3v.)

Quindi il BRACCIO assorbe 4,5 volte più corrente quando è sveglio e 10 volte quando dorme. Non sembra molto, ma è la differenza tra correre su una cella a bottone per 3 mesi o per un anno. (Suppongo che entrambi i microcontrollori stiano eseguendo principalmente tempismo, aggiornando le porte ecc. E non stiano eseguendo calcoli pesanti. In quest'ultimo caso, e il micro a 8 bit deve fare un sacco di aritmetica multi-byte per un lungo periodo di tempo, perde parte del suo vantaggio.)

È interessante notare che l'ARM assorbe circa quattro volte più corrente dell'8 bitter e che a sua volta ha registri interni e percorsi di dati quattro volte più ampi. Non credo sia una coincidenza. Per CMOS, il consumo di energia è approssimativamente proporzionale al numero di transistor commutati e l'ARM sta ovviamente facendo molto di più per istruzione eseguita.

Dato che un maggior numero di venditori ARM produce chip di fascia bassa, non sarei sorpreso se venditori come Microchip abbassassero ulteriormente i loro prezzi. In ogni caso, con i prezzi più o meno uguali, pacchetti di dimensioni simili, ma molto meno chip a 32 bit tra cui scegliere, penso che i microcontrollori a 8 bit rimarranno ancora in circolazione per un po ', soprattutto perché hai ho avuto decine di migliaia di ingegneri familiari con loro.

Tre punti principali:

• Prezzo
• Dimensione
• Consumo di energia

50 ¢ quando si ordinano 10.000 gettoni è piuttosto un sacco di soldi. Ancora di più quando ordini 100.000 chip.

Puoi ottenere chip a 8 bit considerevolmente più piccoli dei chip a 32 bit, come il PIC10 disponibile in un pacchetto SOT23-6.

I chip a 32 bit, poiché sono generalmente più veloci e fanno di più, consumano molta più energia rispetto a un piccolo chip a 8 bit. Le batterie si scaricano più velocemente, i sistemi di alimentazione devono fornire più corrente (e quindi essere più costosi), ecc.

Dopo tutto, perché dovresti comprare un juggernaut per prendere una tazza di zucchero accanto?

Le applicazioni uC che ho sviluppato per prodotti commerciali non hanno quasi mai gestito dimensioni di dati superiori a 8 bit; quindi, anche se i 32 bitters avessero lo stesso prezzo degli 8 bitter, non ci sarebbero comunque vantaggi. Come ha detto qualcun altro, cerchiamo ciò che è familiare, in modo da poterlo dare più rapidamente. L'ultimo che ho sviluppato, tuttavia, si è rivelato in grado di spingere il PIC16 al limite in ogni modo, ma ciò non era dovuto alla dimensione dei dati. Se lo faccio più, allora dovrei davvero imparare ARM.

Mi aspetto che i chip ARM assumano la maggior parte delle funzioni in cui qualcosa si comporta come un "computer". D'altra parte, molti microcontrollori a 8 bit si abituano a fare cose che potrebbero essere fatte con un dispositivo logico programmabile relativamente semplice o un numero moderato di porte, ma in realtà possono essere fatte più economiche e / o con meno corrente assorbita usando un semplice micro a 8 bit. Quando si progettano applicazioni più complicate, è spesso più facile utilizzare un micro a 32 bit rispetto a uno a 8 bit, ma se lo scopo di un chip è, ad esempio, guardare e rimbalzare un determinato input e, se aumenta, iniziare a produrre 200 pulsa su una determinata uscita a intervalli di 1 ms, quindi 100 a intervalli di 2 ms, quindi 100 a 3 ms, quindi pausa per 100 ms e continua a farlo fino a quando l'input diventa basso, progettando il codice per quello potrebbe effettivamente essere più facilesu un micro a 8 bit che su uno a 32 bit. La differenza di costo tra micros a 8 e 32 bit potrebbe non essere più sufficiente in molti casi per giustificare la spesa di ulteriori sforzi di ingegneria per rendere un progetto "adatto" in un micro a 8 bit, ma nei casi in cui una parte a 32 bit non sarebbe per risparmiare ogni sforzo di ingegneria non c'è motivo di spendere nemmeno un centesimo in più.

Mentre sono d'accordo sul fatto che il costo della CPU e il consumo energetico sono i motivi principali, un'altra considerazione che non ho ancora visto elencato qui è lo spazio PCB. Per molti tipi di sistemi embedded, come, per esempio, una bilancia elettronica da bagno, non c'è molto bisogno di un sacco di I / O, nessun vantaggio per le dimensioni del bus più grandi e nessun vantaggio per un'elaborazione più veloce. Tuttavia, non v'èun vantaggio per un pacchetto più piccolo con meno pin perché rende più semplice e spesso più piccolo il layout e il routing di un circuito stampato. Se una scheda può essere progettata come una scheda a 2 strati anziché come una a 4 strati, si ottiene un notevole risparmio sui costi e i conteggi dei pin più piccoli che spesso vengono forniti con processori a 8 bit tendono a facilitare tali risparmi più rapidamente di 32- processori di bit che generalmente hanno più pin e pacchetti fisicamente più grandi.

Anche nel mondo a 8 bit, è noto che i tipi più recenti impiegano tempi molto lunghi per prendere il posto dei tipi più vecchi - vedi MCS51 essere ancora vivo nelle sue nicchie e MCS48 ancora trovato in luoghi inaspettati.

In molti casi, il cambiamento non avviene perché non apporta alcun valore aggiuntivo e comporta il costo dell'apprendimento di una nuova tecnologia che non ha ancora dimostrato di essere lì per rimanere e / o che dovrebbe essere ancora un obiettivo mobile (il che rende è interessante per le persone che vogliono concentrarsi sulla tecnologia MCU ma fastidiose per le persone che vogliono concentrarsi sulla loro applicazione e non riparare e ripetere il test del software di produzione costantemente per adattare l'annata ARM di quest'anno!). Per alcuni, un componente non più sviluppato è obsoleto, per altri è diventato finalmente stabile , e mentre potrebbe aver bisogno di soluzioni alternative per i bug incarniti, almeno fornisce una piattaforma stabile per questi. Il flusso di lava non è sempre l'antipasto che viene spezzato per fare in modo che le montagne rimangano il posto giusto.