Come si comporta un Cortex M0 rispetto ai controller a 8 bit?

Questo documento cita 60 DMIPS / mW per un Cortex M0, contro 31 DMIPS / mW per un M3. (Quest'ultimo non è d'accordo con i numeri in questo documento , che citano 1,25 DMIPS / MHz e 0,19 mW / MHz, dando 6,6 DMIPS / mW.)
Qualcuno sa come le prestazioni / potenza M0 si confrontano con i controller a 8/16 bit come AVR, PIC e MSP430? E qual è il problema con le figure M3?

microcontroller performance

— Federico Russo
fonte

@frederico questa è una domanda molto carica e non c'è una risposta facile. Da allora, la mia esperienza è che le altre cose determinano le prestazioni .. Cose come capacità di precaricamento, velocità del bus, numero di periferiche sospese su un bus, velocità di accesso flash ecc. Ecc. Se si profila bene un sistema, quasi sempre si vede ottenere i dati e fuori diventa il collo di bottiglia. Bene, se descrivi in dettaglio la tua applicazione, sarei felice di fornirti informazioni su quale sia il percorso migliore per scegliere il processore.

— Frank

@Frank: il benchmark Dhrystone non tiene conto implicitamente di cose come il prefetch e la velocità del bus? In particolare, vorrei chiarire le figure contraddittorie dell'NXP M3. Non posso darti dettagli sull'app, perché i dettagli non esistono ancora :-)

— Federico Russo

@Frederico, mi considero un ingegnere sotto la media, certamente non un architetto. Non mi fido di alcun benchmark là fuori poiché i dati sono quasi sempre massaggiati. Ad esempio, se si dispone di un sink di dati ad alta velocità che richiede l'inserimento e l'uscita dei dati e nel frattempo è necessario accedere alla memoria e ad altre periferiche, questo case bus si mette in mezzo. Questi processori sono progettati per casi d'uso medi. Se si sta eseguendo una decodifica soft di determinati dati che richiedono più memoria di lettura / scrittura e il percorso dei dati potrebbe traboccare o morire di fame. Questo di solito finisce in notti insonni per i ragazzi del software.

— Frank

In questi giorni il Dhrystone è un giocattolo divertente ma non ti dice molto. I benchmark in generale non ti dicono molto. Devi prendere la tua applicazione ed eseguirla. Il compilatore che scegli di non modificare alcun codice o hardware può fare più volte una differenza di prestazioni più o meno, quindi tutto ciò è molto difficile. Puoi fare benchmark che fanno mostrare ai numeri quello che vuoi.

— old_timer

Il ARM farà il giro degli altri per prestazioni pure (a dimensioni simili e prezzo simile, non necessariamente potenza). Non penso che nemmeno un 8051 sia lento come un PIC, puoi capire il numero di orologi persi per fare qualcosa di utile? Usando asm, la gente usa C e diventa insopportabile da guardare. Il msp430, probabilmente lo vuoi per le app in cui lo spegni, si sveglia una volta in una luna blu fa un paio di cose e poi va a dormire, come un telecomando del televisore o qualcosa del genere.

— old_timer

Risposte:

Ecco un paio di suggerimenti che posso fornire. Le specifiche fornite da NXP riguardano l'intero chip (core, memoria, periferiche). Le specifiche fornite da ARM si basano solo sul core. Dato che i numeri sono derivati in modo diverso, è davvero difficile fare il confronto.

Quindi, propongo di fare un passo indietro e esaminare due dispositivi. Un MCU basato su NXP M0 e un MCU basato su MXP M3.

Per la MCU basata su M0 diamo un'occhiata a LPC1111. Quando questa MCU sta eseguendo un loop inattivo occupato consumerà 3 mA di corrente a una frequenza di clock di 12 MHz. Ciò produce 250uA / MHz, che a 3,3 V è 825uW / MHz.

Per la MCU basata su M3 diamo un'occhiata a LPC1311. Quando questa MCU sta eseguendo lo stesso loop inattivo occupato, consumerà 4 mA di corrente a 12 MHz. Produce 333.3uA / MHz, che è 1.1mW / MHz.

Se osserviamo un MCU MSP430C1101 (16 bit) vedremo che userà 240uA a 1MHz quando la tensione è 3V. Ciò produce 720uW / MHz.

Quindi, passiamo a ATMega328 (utilizzato in Arduino Uno). Vediamo 200uA usati a 1MHz con una tensione di 2V. Ciò produce 400uA / MHz.

Va inoltre notato che MSP430 e AVR sono specificati diversamente. Il loro consumo energetico è dato a 1MHz, mentre come M0 e M3 sono dati a 12MHz. Ciò significa che M0 e M3 presentano inefficienze di ridimensionamento fino a 12 MHz inserite nei loro numeri.

Questi valori sono tutti i numeri di consumo corrente attivi. Se si osserva il consumo corrente quando il dispositivo si trova in uno stato di sospensione, si vedono ordini di grandezza meno energia in uso. Il vantaggio offerto dall'M0 a 32 bit è che può svolgere molto più lavoro in meno tempo rispetto all'MCU a 8 e 16 bit. Ciò significa che per un determinato carico di lavoro trascorrerà molto più tempo in uno stato di sospensione. L'M0 nelle mani di un buon ingegnere spesso ottiene un'efficienza energetica molto migliore rispetto a un MCU a 8 bit nelle mani di un ingegnere meno esperto nonostante le differenze nel consumo di energia attiva.

Dalla mia esperienza, M0 è così vicino al consumo energetico attivo a 16 e 8 bit che puoi compensare molte delle differenze nell'applicazione. Inoltre, molte volte il consumo energetico di tutto ciò che hai appeso all'MCU riduce l'MCU. Quindi, per molte applicazioni che affrontano l'efficienza dell'MCU non è la cosa più importante.

Spero che aiuti. È un lungo modo di dire che il consumo di energia è un po 'peggio, ma si ottiene molto di più con quei cicli di clock rispetto ad altri chip. Quindi, dipende davvero dalla tua applicazione.

— tallganglyguy
fonte

Per quanto riguarda il tuo primo paragrafo: se le figure ARM sono quasi al centro, dovrebbero essere più alte delle figure NXP, che includono la potenza delle periferiche. Ma sono più bassi. Neanche io posso spiegarlo.

— Stevenvh,

Inoltre, è necessario confrontare i controller alla stessa tensione. Se usi LPC1111 a 3V come MSP430, il consumo di energia è molto vicino. Non male per l'ARM NXP; MSP430 è noto per la sua bassa potenza.

— stevenvh

un grosso problema che ho riscontrato con i dispositivi ARM cortx rispetto a MSP430 è che i dispositivi ARM possono masterizzare molti cicli del processore tornando allo stato di funzionamento dalla loro modalità a basso consumo. I dati RAM vengono persi e devono essere ricreati / inizializzati (a parte la SRAM supportata da batteria), il sistema PLL e il clock devono essere riavviati. L'MSP riprende dalla prossima istruzione con tutta la RAM intatta da quando è andata a dormire. Se il tuo processo prevede frequenti transizioni tra le modalità attiva e di sospensione, il ARM perderà.

— uɐɪ

Il confronto tra 12 MHz e 1 MHz è distorto: frequenze di clock più elevate richiedono meno corrente per MHz. Ad esempio gli ultimi MSP430 possono arrivare a 80-120uA per MHz con 8 / 16MHz in modalità attiva.

Vale la pena ricordare che il codice scritto correttamente mantiene la modalità attiva dell'MCU al di sotto dell'1% (o anche dello 0,1%) di tempo, quindi le modalità di alimentazione fanno molta differenza qui.

Nella vita reale gli MSP430 sono difficili da battere (non sono un impiegato TI) a causa di stati di basso consumo molto utili in cui altri MCU impiegano più tempo a svegliarsi o a non mantenere i contenuti RAM, il che è ridicolo.

— user19790
fonte