Avantages des microprocesseurs 32 bits 48-96 Mhz (comme dans Arduino Due)

10

Il semble qu'Arduino Due (32 bits, 84 MHz, SAM3X8E basé sur ARM-Cortex-M3) soit sorti aujourd'hui.

De plus, il existe clairement une myriade de processeurs dans cette catégorie (32 bits / 48-96 Mhz / ARM) ainsi que des cartes de prototypage correspondantes:

  • NXP LPC1768 / mBed
  • STM32 / Découverte
  • PIC32 / ChipKit
  • Hélice PIC32 / Parallax
  • Launchpad LM4F120 / TI
  • etc.

J'essaie de comprendre l'attrait de ces microprocesseurs "intermédiaires", qui me semblent se situer entre les AVR / MSP430 / etc bas de gamme. (avantages: peu coûteux, faible puissance, faible encombrement) et l'ARM7 haut de gamme / etc (pro: capable de beaucoup plus d'instructions par seconde).

Dans quelles situations ou de quelle manière les microprocesseurs 32 bits / 48-96 MHz / ARM sont-ils un choix approprié? Plus précisément, je me demande dans quelles applications ou dans quels paramètres ils feraient un choix supérieur lors de la conception, par rapport aux microcontrôleurs 8 bits bas de gamme ou aux processeurs ARM7 très haut de gamme.

arduino microcontroller microprocessor architecture Thomas E
la source
Eh bien - première chose dans mon esprit, vous pouvez traiter des flux vidéo en direct - où l'Arduino ne pouvait pas gérer cela. Il permet également des algorithmes de chiffrement avancés ou de hachage (plus rapide et plus facile que dans Arduino) Je suis surpris que l'Arduino soit sorti avec une plate-forme 32 bits mais cela vous montre juste - Certaines personnes veulent juste faire plus que contrôler un relais. C'est une belle journée pour Arduino!
Piotr Kula
Vous ne ferez pas plus qu'un traitement vidéo en direct trivial sur un processeur <100 MHz, à moins que vous ne le fassiez dans un noyau de fonction spéciale attaché. Et surtout pas dans le bélier embarqué assez limité de ces appareils. Un point plus réaliste est que le coût de ces puces n'est tout simplement pas beaucoup plus élevé que celui des pièces 8 bits; il peut en réalité être inférieur à un ATMEGA avec flash et RAM comparables.
Chris Stratton
3
Pour autant que je sache, Parallax Propeller est une puce personnalisée sans relation avec PIC32. Des sources de connexion?
AndrejaKo

Réponses:

12

C’est l’un de ces sujets qui peuvent faire l’objet de débats. Il y a tellement de points de vue différents et différentes choses sont importantes pour différentes personnes. Je vais essayer de donner une réponse complète, mais je comprends qu'il y aura toujours quelqu'un qui ne sera pas d'accord. Comprenez simplement que ceux qui ne sont pas d'accord avec moi ont tort. (Je rigole.)

Résumé rapide:

Cette réponse va être longue, alors permettez-moi de résumer cela à l'avance. Pour la grande majorité des gens, la dernière génération de puces ARM Cortex-M0 / M3 / M4 offre la meilleure solution, les meilleures fonctionnalités pour le coût. Cela est même vrai lorsque l'on compare ces MCU 32 bits à leurs ancêtres 8 et 16 bits comme les PIC et MSP430. Les M0 peuvent être achetés pour moins de 1 $ US / pièce et les M4 pour moins de 2 $ US / pièce, donc à l'exception des applications très sensibles au prix, les solutions ARM sont très agréables. Les M0 sont de très faible puissance et devraient être assez bons pour la plupart des gens. Pour ceux qui sont très sensibles à la puissance, les MSP430 pourraient toujours être un meilleur choix, mais les M0 méritent d'être envisagés même pour ces applications.

Si vous êtes intéressé par une analyse plus approfondie, poursuivez votre lecture, sinon vous pouvez arrêter de lire maintenant.

Je vais maintenant regarder chaque zone et comparer les différents MCU:

Rapidité d'exécution

Bien sûr, les MCU 32 bits vont être plus rapides. Ils ont tendance à avoir une vitesse d'horloge plus rapide, mais font également plus de travail pour chacune de ces horloges. Les microcontrôleurs comme l'ARM Cortex-M4 incluent des instructions de traitement DSP et peuvent même prendre en charge la virgule flottante dans le matériel. Les processeurs 8 et 16 bits peuvent fonctionner sur des nombres 32 bits, mais cela n'est pas efficace. Cela consommera rapidement les registres du processeur, les cycles d'horloge du processeur et la mémoire flash pour le stockage du programme.

Facilité de développement

À mon avis, c'est la raison la plus valable pour utiliser des MCU 32 bits modernes - mais aussi la plus sous-estimée. Permettez-moi d'abord de comparer cela aux PIC 8 bits. C'est la pire des comparaisons, mais aussi la meilleure pour illustrer mes propos.

Les PIC plus petits nécessitent essentiellement que la programmation soit effectuée en langage assembleur. Certes, il existe des compilateurs C disponibles même pour les PIC 8 bits, mais ces compilateurs sont gratuits ou bons. Vous ne pouvez pas obtenir un compilateur à la fois bon et gratuit. La version gratuite du compilateur est paralysée en ce que son optimisation n'est pas aussi bonne que la version "Pro". La version Pro coûte environ 1 000 $ US et ne prend en charge qu'une seule famille de puces PIC (puces 8, 16 ou 32 bits). Si vous souhaitez utiliser plusieurs familles, vous devez acheter un autre exemplaire pour 1 000 $ US supplémentaires. La version "Standard" du compilateur fait un niveau moyen d'optimisation et coûte environ 500 $ US pour chaque famille de puces. Les PIC 8 bits sont lents par rapport aux normes modernes et nécessitent une bonne optimisation.

En comparaison, il existe de nombreux bons compilateurs C pour les MCU ARM qui sont gratuits. Lorsqu'il existe des limitations, ces limites concernent généralement la taille maximale de la mémoire flash prise en charge. Sur les outils Freescale Codewarrior, cette limite est de 128 Ko. C'est beaucoup pour la plupart des gens sur ce forum.

L'avantage d'utiliser un compilateur C est que vous n'avez pas à vous soucier (autant) des détails de bas niveau de la carte mémoire du CPU. La pagination sur le PIC est particulièrement douloureuse et il est préférable d'éviter autant que possible. Un autre avantage est que vous n'avez pas à vous soucier du traitement des numéros 16 et 32 ​​bits sur un MCU 8 bits (ou des numéros 32 bits sur un MCU 16 bits). Bien qu'il ne soit pas super difficile de le faire en langage d'assemblage, c'est une douleur à l'arrière et est sujet aux erreurs.

Il existe d'autres compilateurs non ARM C qui fonctionnent bien. Le compilateur MSP430 semble faire un travail raisonnable. Les outils Cypress PSoC (en particulier PSoC1) sont bogués.

Modèle de mémoire plate

Un MCU qui a paginé RAM / registres / Flash est tout simplement stupide. Oui, je parle des PIC 8 bits. Muet, muet, muet. Cela m'a tellement détourné des PIC que je n'ai même pas pris la peine de regarder leurs nouveautés. (Avertissement: cela signifie que les nouveaux PIC pourraient être améliorés et je ne le sais tout simplement pas.)

Avec une MCU 8 bits, il est difficile (mais pas impossible) d'accéder à des structures de données supérieures à 256 octets. Avec un MCU 16 bits qui passe à 64 kilo-octets ou k mots. Avec des microcontrôleurs 32 bits pouvant atteindre 4 gigaoctets.

Un bon compilateur C peut en cacher beaucoup au programmeur (alias You), mais même dans ce cas, cela affecte la taille du programme et la vitesse d'exécution.

Il existe de nombreuses applications MCU pour lesquelles cela ne sera pas un problème, mais bien sûr, il y en a beaucoup d'autres qui auront des problèmes avec cela. Il s'agit principalement de la quantité de données dont vous avez besoin (tableaux et structures) en RAM ou Flash. Bien sûr, à mesure que la vitesse du processeur augmente, les chances d'utiliser des structures de données plus grandes augmentent également!

Taille du paquet

Certains des petits PIC et autres MCU 8 bits sont disponibles dans de très petits packages. 6 et 8 broches! Actuellement, le plus petit ARM Cortex-M0 que je connaisse se trouve dans un QFN-28. Bien qu'un QFN-28 soit suffisamment petit pour la plupart, il n'est pas assez petit pour tous.

Coût

Le PIC le moins cher est environ un tiers du prix de l'ARM Cortex-M0 le moins cher. Mais c'est vraiment 0,32 $ US contre 0,85 $ US. Oui, cette différence de prix est importante pour certains. Mais je suppose que la plupart des gens sur ce site Web ne se soucient pas de cette petite différence de coût.

De même, lorsque l'on compare des microcontrôleurs plus performants avec l'ARM Cortex-M0 / M3 / M4, l'ARM Cortex sort généralement "à peu près même" ou en haut. En tenant compte des autres choses (facilité de développement, coûts du compilateur, etc.), les ARM sont très attractifs.

Deuxième résumé

Je suppose que la vraie question est: pourquoi n'utilisez-vous PAS un ARM Cortex-M0 / M3 / M4? Quand le coût absolu est super important. Lorsqu'une consommation d'énergie extrêmement faible est critique. Lorsque le plus petit format d'emballage est requis. Quand la vitesse n'est pas importante. Mais pour la grande majorité des applications, aucune d'entre elles ne s'applique et l'ARM est actuellement la meilleure solution.

Étant donné le faible coût, à moins qu'il n'y ait une bonne raison de ne pas utiliser un ARM Cortex, il est logique d'en utiliser un. Il permettra un temps de développement plus rapide et plus facile avec moins de maux de tête et des marges de conception plus importantes que la plupart des autres microcontrôleurs.

Il existe d'autres MCU non ARM Cortex 32 bits, mais je ne vois aucun avantage pour eux non plus. Il existe de nombreux avantages à utiliser une architecture CPU standard, notamment de meilleurs outils de développement et une innovation plus rapide de la technologie.

Bien sûr, les choses peuvent changer et changent. Ce que je dis est valable aujourd'hui, mais pourrait ne pas l'être dans un an ou même dans un mois. Faites vos propres devoirs.


la source
1
Pour accéder à n'importe quel emplacement de mémoire avec l'ARM, il faut d'abord charger un registre avec une adresse qui est à moins de 4K de celui-ci; de nombreux périphériques d'E / S se voient allouer plus de 4K d'espace d'adressage, même si beaucoup n'utilisent que quelques adresses discrètes. En revanche, les PIC 18Fxx peuvent fonctionner directement sur la plupart des emplacements d'E / S avec une seule instruction, indépendamment de l'état de la banque. Le moyen par lequel la majeure partie de la RAM est mise en banque est plutôt ennuyeux, mais pour certains types de bit-banging (le but pour lequel l'architecture PIC a été conçue dans les années 1970), l'architecture PIC fonctionne très bien.
supercat
1
BTW, je trouve curieux que bien qu'un microprocesseur 8 bits populaire des années 1970 puisse traiter efficacement des structures de données de 256 octets alignées arbitrairement, et un processeur 16 bits populaire pourrait bien fonctionner avec des structures de données de 65 536 octets alignées sur 16 les limites d'octet ou les structures de données arbitrairement alignées presque aussi grandes, les nouveaux processeurs 8 bits et 16 bits rendent difficile l'écriture de code efficace qui chevauche les limites des pages / banques.
supercat
@supercat La plage d'adresses 4K pour une instruction "LDR / SRT Immediate Offset" est vraie, mais souvent ce n'est pas un problème. Je ne suis pas d'accord avec le reste de votre commentaire. En regardant les documents Freescale M4, chaque périphérique ne prend pas plus de 4K de plage d'adresses, donc un seul "pointeur d'adresse de base" est suffisant pour accéder à tous les registres de ce périphérique. Il existe également 32 registres à usage général, dont chacun peut être utilisé comme pointeur d'adresse de base - afin d'accéder rapidement à plusieurs périphériques dans la même section de code est relativement indolore.
1
@supercat Votre deuxième point concerne l'ensemble du débat RISC vs CISC. ARM est un processeur RISC, ce qui signifie qu'il est optimisé pour effectuer les tâches les plus fréquentes. Les tâches qui ne sont pas fréquentes, comme les accès non alignés, nécessitent soit plus de travail, soit plus de temps (en fonction de la CPU Arch). Je considère que c'est une chose positive, pas une chose négative. C'est pourquoi nous obtenons des MCU 32 bits rapides pour le prix d'un 8 bits plus ancien. Même avec ces bizarreries, je prendrais l'un de ces CPU sur un PIC tous les jours.
Je me suis mal exprimé; Je ne voulais pas impliquer qu'un registre de base ne pouvait pas gérer un périphérique entier, mais plutôt qu'un registre devrait souvent être chargé pour chaque périphérique (donc on ne pouvait pas simplement, par exemple, laisser un registre assis avec IO_BASE_ADDR tout le temps ). Pour certains types de code, la possibilité de définir un bit d'E / S en un seul cycle avec une instruction comme "bsf LATA, 4", sans avoir à précharger les registres au préalable, peut être très pratique. J'aime l'ARM, mais le mappage d'E / S direct sur le PIC peut être assez agréable (dommage que les autres accès à la mémoire ne soient pas aussi agréables).
supercat
3

David Kessner a raison. Je voudrais ajouter ce qui suit.

  1. Les MCU 8 bits sont les seuls MCU facilement disponibles dans les packages PDIP qui sont faciles à manipuler et à coller dans une maquette de prototypage.
  2. Les MCU 32 bits peuvent en fait utiliser moins d'énergie que les MCU 8 bits. Il n'est pas nécessairement vrai que le MCU <20 MHZ 8 bits utilisera moins d'énergie qu'un Cortex M4.
  3. Les MCU 8 bits sont souvent utilisés par les amateurs qui n'ont généralement pas besoin de beaucoup de MCU. Peut-être quelques centaines de lignes de code C simple.

Je suis d'accord que de nos jours, il n'y a pas de raison de ne pas utiliser de microcontrôleurs 32 bits. Je ne les utiliserais que [MCU 8 bits] pour 2 raisons: j'aime la facilité du package PDIP (aucune soudure requise); Souvent, je n'ai pas besoin de plus de puissance / complexité que ce qu'un MCU 8 bits peut offrir.

Le disjoncteur est vraiment les outils disponibles.

s5s
la source
Pour le prototypage, il existe des sockets pour LQFP, qui fonctionnent assez bien. Et bien sûr, vous pouvez souder LQFP à la main, cela demande juste un peu de pratique. QFN, DFN et BGA Je ne souderais pas à la main, mais tous les MCU 32 bits bas de gamme du marché sont livrés avec LQFP.
Lundin
1

Nous utilisons un Freescale MCF52259 relativement démodé, un MCU compatible 32 bits ~ 80 MHz.

Les raisons / processus de réflexion pour le choix étaient:

  • Il remplaçait un périphérique M.Core 32 bits, donc le portage était relativement simple
  • Cela signifiait également que nous pouvions nous en tenir à l'IDE existant (CodeWarrior)
  • Nous avions besoin de beaucoup d'E / S: Contrôle de pas / direction sur 3 moteurs pas à pas, 4 canaux de PWM, 3 UART et I2C et SPI.
  • Il se passait beaucoup de choses (voir dernier point) et certaines devaient se produire en temps opportun, nous devions donc être sûrs qu'il y avait suffisamment de cycles CPU pour que tout soit fait.
  • Le code hérité se heurtait à la taille du flash 256k et à la mémoire RAM 32k du M.Core, donc doubler le flash et la RAM rendait la vie facile à installer et à fonctionner rapidement.

De nos jours, il est plus rentable (et plus opportun) de sur-spécifier / étendre les capacités du matériel (stockage, vitesse, E / S, etc.) que de passer un temps de développement précieux à optimiser le code pour se faufiler dans un MCU légèrement moins cher / plus petit, sauf si l'espace ou le pouvoir sont de gros problèmes.

Dans notre cas, l'appareil était le double de la spécification du M.Core pour la moitié du prix, aller à un MCU moins cher ne ferait que gagner quelques sous par carte, mais coûterait beaucoup de temps de développement et limiterait le potentiel de développement futur sans changer à nouveau les MCU.

Si nous construisions un million de cartes, cela vaudrait la peine de faire l'exercice de calcul des coûts pour réduire les choses, mais en l'état, cela ne vaut pas le temps de développement.

John U
la source