Comment fonctionne un Cortex M0 par rapport aux contrôleurs 8 bits?

Ce document cite 60 DMIPS / mW pour un Cortex M0, contre 31 DMIPS / mW pour un M3. (Ce dernier n'est pas d'accord avec les chiffres de ce document , qui citent 1,25 DMIPS / MHz et 0,19 mW / MHz, ce qui donne 6,6 DMIPS / mW.)
Quelqu'un sait-il comment les performances / puissance du M0 se comparent aux contrôleurs 8/16 bits comme AVR, PIC et MSP430? Et quel est le problème avec les chiffres M3?

microcontroller performance

— Federico Russo
source

@frederico c'est une question très chargée et il n'y a pas de réponse facile. Depuis, mon expérience est que les autres éléments déterminent les performances. et devient le col de la bouteille. Eh bien, si vous détaillez votre application, je serais heureux de vous donner un aperçu de la meilleure façon de choisir le processeur.

— Frank

@Frank: le benchmark Dhrystone ne prend-il pas implicitement en compte des éléments comme la prélecture et la vitesse du bus? Je voudrais en particulier que les chiffres contradictoires du NXP M3 soient clarifiés. Je ne peux pas vous donner de détails sur l'application, car les détails n'existent pas encore :-)

— Federico Russo

@Frederico, je me considère comme un ingénieur en dessous de la moyenne, certainement pas un architecte. Je ne fais confiance à aucune référence, car les données sont presque toujours massées. Par exemple, si vous avez un récepteur de données à grande vitesse qui vous oblige à pousser des données vers l'intérieur et vers l'extérieur et en attendant que vous ayez besoin d'accéder à la mémoire et à d'autres périphériques, ce bus de cas se met en travers. Ces processeurs sont conçus pour les cas d'utilisation moyens. Si vous effectuez un décodage en douceur de certaines données qui nécessitent plusieurs lectures / écritures en mémoire et que le chemin de données peut déborder ou mourir de faim. Cela se termine généralement par des nuits blanches pour les gars du logiciel.

— Frank

Ces jours-ci, le Dhrystone est un jouet amusant mais ne vous dit pas grand-chose. Les repères en général ne vous disent pas grand-chose du tout. Vous devez prendre votre application et l'exécuter. Le compilateur que vous choisissez de ne changer aucun code ou matériel peut faire une différence de performance de plusieurs fois plus ou moins, donc tout cela est très difficile. Vous pouvez faire des repères qui font que les chiffres montrent ce que vous voulez.

— old_timer

L'ARM va faire le tour du reste pour des performances pures (à une taille et à un prix similaires, pas nécessairement une puissance). Je ne pense pas que même un 8051 soit aussi lent qu'un PIC, pouvez-vous comprendre le nombre d'horloges perdues pour faire quelque chose d'utile? En utilisant asm, les gens utilisent C et cela devient insupportable à regarder. Le msp430, vous le voulez probablement pour les applications où vous l'éteignez, il se réveille une fois dans une lune bleue fait quelques choses puis se met en veille, comme une télécommande de télévision ou quelque chose comme ça.

— old_timer

Réponses:

Voici quelques conseils que je peux vous fournir. Les spécifications fournies par NXP concernent l'ensemble de leur puce (cœur, mémoire, périphériques). La spécification fournie par ARM est basée uniquement sur le cœur. Comme les chiffres sont dérivés différemment, il est vraiment difficile de faire la comparaison.

Je propose donc de prendre du recul et d'examiner deux appareils. Un MCU basé sur NXP M0 et un MCU basé sur MXP M3.

Pour le MCU basé sur M0, regardons le LPC1111. Lorsque ce MCU exécute une boucle inactive occupée, il consomme 3 mA de courant à une fréquence d'horloge de 12 MHz. Cela donne 250uA / MHz, ce qui à 3,3 V est 825uW / MHz.

Pour le MCU basé sur M3, regardons le LPC1311. Lorsque ce MCU exécute la même boucle inactive occupée, il consommera 4 mA de courant à 12 MHz. Rendement 333,3 uA / MHz, soit 1,1 mW / MHz.

Si nous regardons un MCU MSP430C1101 (16 bits), nous verrons qu'il va utiliser 240uA à 1MHz lorsque la tension est de 3V. Cela donne 720uW / MHz.

Passons maintenant à l'ATMega328 (utilisé dans Arduino Uno). On voit 200uA utilisé à 1MHz avec une tension de 2V. Cela donne 400uA / MHz.

Il convient également de noter que le MSP430 et l'AVR sont spécifiés différemment. Leur consommation d'énergie est donnée à 1 MHz, alors que les M0 et M3 sont donnés à 12 MHz. Cela signifie que les M0 et M3 ont des inefficacités de mise à l'échelle jusqu'à 12 MHz cuits dans leurs nombres.

Ces valeurs sont toutes des valeurs de consommation actuelles actives. Si vous regardez la consommation actuelle lorsque l'appareil est en veille, vous voyez des ordres de grandeur moins d'énergie utilisée. L'avantage du M0 32 bits est qu'il peut faire beaucoup plus de travail en moins de temps que le MCU 8 et 16 bits. Cela signifie que pour une charge de travail donnée, il passera beaucoup plus de temps en sommeil. Le M0 entre les mains d'un bon ingénieur obtiendra souvent une efficacité énergétique bien meilleure qu'un MCU 8 bits entre les mains d'un ingénieur moins qualifié malgré les différences de consommation d'énergie active.

D'après mon expérience, le M0 est si proche de la consommation d'énergie active de 16 et 8 bits que vous pouvez compenser beaucoup de différences dans l'application. En outre, la consommation électrique de tout ce que vous avez suspendu au MCU est souvent supérieure à celle du MCU. Donc, pour de nombreuses applications, la gestion de l'efficacité du MCU n'est pas la chose la plus importante.

J'espère que ça aide. C'est une longue façon de dire que la consommation d'énergie est un peu pire, mais vous faites beaucoup plus avec ces cycles d'horloge que les autres puces. Cela dépend donc vraiment de votre application.

— tallganglyguy
source

Concernant votre premier paragraphe: si les chiffres ARM sont à peu près au cœur, ils devraient être supérieurs aux chiffres NXP, qui incluent la puissance des périphériques. Mais ils sont plus bas. Je ne peux pas l'expliquer non plus.

— stevenvh

En outre, vous devez comparer les contrôleurs à des tensions égales. Si vous utilisez le LPC1111 à 3 V comme le MSP430, leur consommation d'énergie est très proche. Pas mal pour le NXP ARM; le MSP430 est connu pour sa faible puissance.

— stevenvh

un gros problème que j'ai eu avec les appareils ARM cortex par rapport au MSP430 est que les appareils ARM peuvent graver beaucoup de cycles de processeur pour revenir à l'état de fonctionnement à partir de leur mode basse consommation. Les données RAM sont perdues et doivent être recréées / initialisées (à l'exception de la SRAM alimentée par batterie), le PLL et le système d'horloge doivent être redémarrés. Le MSP reprend juste à partir de l'instruction suivante avec toute la RAM intacte à partir du moment où il s'est endormi. Si votre processus implique des transitions fréquentes entre les modes actif et sommeil, l'ARM perdra.

— u

La comparaison de 12 MHz à 1 MHz est biaisée - des fréquences d'horloge plus élevées nécessitent moins de courant par MHz. Par exemple, les derniers MSP430 peuvent descendre jusqu'à 80-120uA par MHz avec 8 / 16MHz en mode actif.

Il convient de mentionner que le code correctement écrit maintient le mode actif du MCU en dessous de 1% (ou même 0,1%) de temps, donc les modes d'alimentation font beaucoup de différence ici.

Dans la vie réelle, les MSP430 sont difficiles à battre (je ne suis pas un employé de TI) en raison d'états de faible consommation très utiles où d'autres MCU prennent plus de temps à se réveiller ou ne gardent pas le contenu de la RAM, ce qui est ridicule.

— user19790
source