Quelle est la différence entre les microcontrôleurs 8 bits et les microcontrôleurs 32 bits en ce qui concerne leur programmation

19

Bon, nous avons donc actuellement des microcontrôleurs 8 bits, 16 bits et 32 ​​bits dans ce monde. Tous sont souvent utilisés. En quoi est-ce différent de programmer des microcontrôleurs 8 bits et 16 bits? Je veux dire, cela nécessite-t-il une technique ou une compétence différente? Prenons par exemple la puce électronique. Quelles nouvelles choses une personne doit-elle apprendre si elle souhaite passer des microcontrôleurs 8 bits aux microcontrôleurs 32 bits?

quantum231
la source
Non. Il y a certainement des préoccupations différentes, mais celles-ci concernent en grande partie le niveau de détail spécifique à l'appareil. Par exemple, l'accès aux mots non alignés est-il autorisé? (Sur ARM, ce n'est pas le cas - mais sur x86, c'est le cas). Cette question n'est pas vraiment assez précise.
Chris Stratton
Wow les gars, merci pour les réponses. Il y a donc en fait des différences très importantes que nous devons prendre en compte lors de la programmation de processeurs 32 bits vs processeurs 8 bits. Ici, je faisais référence à C car je pense que la plupart des gens ne se plongent pas dans Assembly pour la programmation pour des raisons que nous connaissons tous très bien. Merci pour les réponses détaillées, je l'apprécie vraiment.
quantum231
Avec les uc 32 bits, il y a BEAUCOUP plus d'options et BEAUCOUP plus de registres que vous devez obtenir correctement. Je suppose que cela dépend de ce que vous faites. Cela dit, ces jours-ci, vous pouvez obtenir un conseil de développement, un compilateur, un débogueur, un IDE pour environ 50 $. Retour dans la journée qui coûterait près de 1000 $.

Réponses:

33

En général, passer de microcontrôleurs de 8 à 16 à 32 bits signifie que vous aurez moins de contraintes sur les ressources, en particulier la mémoire, et la largeur des registres utilisés pour effectuer des opérations arithmétiques et logiques. Les monikers 8, 16 et 32 ​​bits se réfèrent généralement à la fois à la taille des bus de données internes et externes ainsi qu'à la taille du ou des registres internes utilisés pour les opérations arithmétiques et logiques (autrefois appelés un ou deux appelés accumulateurs). , il existe désormais généralement des banques de 16 ou 32 registres).

La taille des ports des ports d'E / S suivra généralement la taille du bus de données, donc un micro 8 bits aura des ports 8 bits, un 16 bits aura des ports 16 bits, etc.

En dépit d'avoir un bus de données 8 bits, de nombreux microcontrôleurs 8 bits ont un bus d'adresse 16 bits et peuvent adresser 2 ^ 16 ou 64 Ko octets de mémoire (cela ne signifie pas qu'ils ont n'importe où près de celui implémenté). Mais certains micros 8 bits, comme les PIC bas de gamme, peuvent ne disposer que d'un espace RAM très limité (par exemple 96 octets sur un PIC16).

Pour contourner leur schéma d'adressage limité, certains micros 8 bits utilisent la pagination, où le contenu d'un registre de page détermine l'une des nombreuses banques de mémoire à utiliser. Il y aura généralement de la RAM commune disponible, quel que soit le registre de pages.

Le microcontrôleur 16 bits est généralement limité à 64 Ko de mémoire, mais peut également utiliser des techniques de pagination pour contourner ce problème. Les microcontrôleurs 32 bits n'ont bien sûr pas de telles restrictions et peuvent traiter jusqu'à 4 Go de mémoire.

Avec les différentes tailles de mémoire est la taille de la pile. Dans les micros d'extrémité inférieure, cela peut être implémenté dans une zone de mémoire spéciale et être très petit (de nombreux PIC16 ont une pile d'appels profonds à 8 niveaux). Dans les micros 16 bits et 32 ​​bits, la pile sera généralement en RAM et ne sera limitée que par la taille de la RAM.

Il existe également de grandes différences dans la quantité de mémoire - à la fois programme et RAM - implémentée sur les différents appareils. Les micros 8 bits peuvent n'avoir que quelques centaines d'octets de RAM et quelques milliers d'octets de mémoire de programme (ou bien moins - par exemple, le PIC10F320 n'a que 256 mots de 14 bits de flash et 64 octets de RAM). Les micros 16 bits peuvent avoir quelques milliers d'octets de RAM et des dizaines de milliers d'octets de mémoire de programme. Les micros 32 bits ont souvent plus de 64 Ko d'octets de RAM et peut-être 1/2 Mo ou plus de mémoire de programme (le PIC32MZ2048 a 2 Mo de flash et 512 Ko de RAM; le PIC32MZ2064DAH176 nouvellement publié, optimisé pour les graphiques, a 2 Mo de flash et un énorme 32 Mo de RAM sur puce).

Si vous programmez en langage assembleur, les limitations de taille de registre seront très évidentes, par exemple, l'ajout de deux nombres 32 bits est une corvée sur un microcontrôleur 8 bits mais trivial sur un microcontrôleur 32 bits. Si vous programmez en C, ce sera largement transparent, mais bien sûr le code compilé sous-jacent sera beaucoup plus grand pour le 8-bitter.

J'ai dit largement transparent, car la taille des différents types de données C peut être différente d'une taille micro à l'autre; par exemple, un compilateur qui cible un micro 8 ou 16 bits peut utiliser "int" pour signifier une variable signée 16 bits, et sur un micro 32 bits ce serait une variable 32 bits. Ainsi, de nombreux programmes utilisent #defines pour indiquer explicitement la taille souhaitée, comme "UINT16" pour une variable 16 bits non signée.

Si vous programmez en C, le plus grand impact sera la taille de vos variables. Par exemple, si vous savez qu'une variable sera toujours inférieure à 256 (ou comprise entre -128 et 127 si elle est signée), vous devez utiliser un 8 bits (caractère non signé ou caractère) sur un micro 8 bits (par exemple PIC16 ), car l'utilisation d'une taille plus grande sera très inefficace. De même pour les variables 16 bits sur un micro 16 bits (par exemple PIC24). Si vous utilisez un micro 32 bits (PIC32), cela ne fait aucune différence puisque le jeu d'instructions MIPS a des instructions d'octet, de mot et de double mot. Cependant, sur certains micros 32 bits, s'ils manquent de telles instructions, la manipulation d'une variable 8 bits peut être moins efficace qu'une variable 32 bits en raison du masquage.

Comme l'a souligné le membre du forum vsz, sur les systèmes où vous avez une variable qui est plus grande que la taille de registre par défaut (par exemple une variable 16 bits sur un micro 8 bits), et cette variable est partagée entre deux threads ou entre le thread de base et un gestionnaire d'interruption, on doit faire n'importe quelle opération (y compris juste la lecture) sur la variable atomique , c'est-à-dire la faire apparaître comme une seule instruction. C'est ce qu'on appelle une section critique. La manière standard d'atténuer ce problème consiste à entourer la section critique d'une paire d'interruption de désactivation / activation.

Donc, passer des systèmes 32 bits à 16 bits, ou 16 bits à 8 bits, toutes les opérations sur les variables de ce type qui sont maintenant plus grandes que la taille de registre par défaut (mais qui ne l'étaient pas auparavant) doivent être considérées comme critiques section.

Une autre différence majeure, passant d'un processeur PIC à un autre, est la gestion des périphériques. Cela a moins à voir avec la taille des mots qu'avec le type et le nombre de ressources allouées sur chaque puce. En général, Microchip a essayé de rendre la programmation du même périphérique utilisé sur différentes puces aussi similaire que possible (par exemple timer0), mais il y aura toujours des différences. L'utilisation de leurs bibliothèques périphériques masquera ces différences dans une large mesure. Une dernière différence est la gestion des interruptions. Encore une fois, il y a de l'aide ici des bibliothèques Microchip.

tcrosley
la source
Il convient de noter qu'au niveau du langage d'assemblage, les processeurs 8 bits ont tendance à avoir moins de registres et moins d'instructions orthogonales (AVR est une exception plus RISCy), une conséquence des contraintes de conception lors de leur développement. Les processeurs 32 bits ont tendance à être des descendants de RISC (le RX de Renesas, un CISC moderne, est une exception, et ColdFire de Freescale descend de m68k).
Paul A. Clayton
9
Pour ne pas commencer une nouvelle réponse juste pour cet ajout, je pense qu'il est important d'ajouter que la transition de 32 bits à 16 de 16 à 8 peut provoquer de mauvaises surprises car les arithmétiques cessent d'être atomiques. Si vous ajoutez deux nombres 16 bits sur un microcontrôleur 8 bits et que vous les utilisez dans une interruption, vous devez vous assurer de les rendre thread-safe, sinon vous risquez d'en ajouter seulement la moitié avant le déclenchement de l'interruption, ce qui entraînera une valeur non valide dans votre routine de service d'interruption.
vsz
2
@vsz - Bon point, j'ai oublié celui-là. En règle générale, il convient de désactiver les interruptions autour de tout accès (y compris la simple lecture) à toute variable volatile supérieure à la taille de registre par défaut.
tcrosley
1
Est-il vrai que les uC 32 bits ont généralement des interfaces d'E / S 32 bits? Je pense que de toute façon, il s'agit le plus souvent d'une communication série.
clabacchio
1
@clabacchio D'après mon expérience, tous les registres de port d'E / S sont définis comme 32 bits, mais parfois les 16 premiers bits 16 à 31 ne sont pas utilisés, donc un port parallèle est toujours composé de 16 broches physiques. Dans d'autres cas, comme un registre RTCC, les 32 bits sont utilisés.
tcrosley
8

Une différence courante entre les microcontrôleurs 8 bits et 32 ​​bits est que les microcontrôleurs 8 bits ont souvent une plage d'espace mémoire et d'E / S accessible en une seule instruction, quel que soit le contexte d'exécution, tandis que les microcontrôleurs 32 bits seront fréquemment nécessitent une séquence d'instructions multiples. Par exemple, sur un microcontrôleur 8 bits typique (HC05, 8051, PIC-18F, etc.), on peut changer l'état d'un bit de port en utilisant une seule instruction. Sur un ARM typique (32 bits), si le contenu du registre était initialement inconnu, une séquence d'instructions de quatre instructions serait nécessaire:

    ldr  r0,=GPIOA
    ldrh r1,[r0+GPIO_DDR]
    ior  r1,#64
    strh r1,[r0+GPIO_DDR]

Dans la plupart des projets, le contrôleur passe la grande majorité de son temps à faire autre chose que de définir ou d'effacer des bits d'E / S individuels, de sorte que le fait que des opérations telles que l'effacement d'une broche de port nécessitent plus d'instructions n'a souvent pas d'importance. D'un autre côté, il y a des moments où le code devra "big bang" beaucoup de manipulations de port, et la possibilité de faire de telles choses avec une seule instruction peut s'avérer très utile.

D'un autre côté, les contrôleurs 32 bits sont invariablement conçus pour accéder efficacement à de nombreux types de structures de données qui peuvent être stockées en mémoire. De nombreux contrôleurs 8 bits, en comparaison, sont très inefficaces pour accéder aux structures de données qui ne sont pas allouées statiquement. Un contrôleur 32 bits peut exécuter dans une instruction un accès à la matrice qui nécessiterait une demi-douzaine d'instructions ou plus sur un contrôleur 8 bits typique.

supercat
la source
Je suppose que vous vouliez dire "bit-bang". Il convient de noter que ARM prend en charge les régions de bande de bits (où les opérations sur les mots sont des opérations sur un seul bit) et l'extension spécifique à l'application MCU pour MIPS fournit un bit défini / effacé de manière atomique dans les instructions d'octet (ASET / ACLR).
Paul A. Clayton
@ PaulA.Clayton: Je n'ai pas vraiment regardé le MIPS au cours des 20 dernières années; en ce qui concerne les régions à bande binaire, je n'ai jamais trouvé de moyen de les utiliser dans un code d'aspect raisonnable, et même si je pouvais les utiliser, elles n'enregistreraient qu'une seule instruction à moins que l'on n'utilise une ruse de programmation insensée, auquel cas ils peuvent enregistrer deux [charger R0 avec une adresse paire ou impaire selon que le bit doit être défini ou effacé, et ajuster le décalage sur l'instruction de stockage comme il convient pour compenser]. BTW, avez-vous une idée pourquoi la région de bande binaire utilise des adresses de mots?
supercat
@supercat: l'adressage Word vous permet d'accéder aux régions de la bande binaire à partir de C ou C ++ via l'indexation de pointeur ( region_base[offset])
Ben Voigt
@BenVoigt Et pourquoi ne pourrait-on pas faire cela avec l'adressage d'octets? (Peut-être qu'une raison possible serait de supprimer l'attente / l'espoir que les opérations à deux et quatre bits soient prises en charge.)
Paul A. Clayton
@BenVoigt: Devoir mettre à l'échelle le nombre de bits par un facteur 4 coûtera souvent une instruction supplémentaire. En fait, ce que j'aurais aimé voir, plutôt qu'une zone de bande binaire, serait un ensemble de deux zones qui se trouveraient à un décalage fixe par rapport aux accès à la mémoire "normaux", mais précisent que les écritures dans une zone ne fera que si possible "définir" les bits, et écrit sur l'autre ne "effacera" que les bits. Si le bus avait des bits de contrôle "écriture-uns-valables" et "écriture-zéros activés" séparés, on pourrait réaliser les choses que la bande de bits permet, mais dans de nombreux cas, éviter la lecture-modification-écriture.
supercat
6

La plus grande différence pratique est la quantité de documentation, vraiment, pour comprendre entièrement la puce entière. Il existe des microcontrôleurs 8 bits avec près de 1 000 pages de documentation. Comparez cela à environ 200 à 300 pages pour un processeur 8 bits des années 80 et les puces périphériques populaires avec lesquelles il serait utilisé. Un périphérique 32 bits riche en périphériques vous obligera à parcourir 2000 à 10 000 pages de documentation pour comprendre la pièce. Les pièces avec un bord graphique 3D moderne sur 20k pages de documentation.

D'après mon expérience, il faut environ 10 fois plus de temps pour tout savoir sur un contrôleur 32 bits moderne donné que pour une partie 8 bits moderne. Par "tout", je veux dire que vous savez comment utiliser tous les périphériques, même de manière non conventionnelle, et que vous connaissez le langage machine, l'assembleur que la plate-forme utilise ainsi que d'autres outils, les ABI, etc.

Il n'est pas du tout inconcevable que beaucoup, beaucoup de conceptions soient faites avec une compréhension partielle. Parfois, c'est sans conséquence, parfois non. Le changement de plate-forme doit être fait en sachant qu'il y aura un prix à court et à moyen terme de la productivité que vous payez pour les gains de productivité perçus d'une architecture plus puissante. Faites preuve de diligence raisonnable.

Réintégrer Monica
la source
3

Personnellement, je ne m'inquiéterais pas trop de la mise à niveau (8 bits -> 32 bits) uC de la même famille et vous augmentez les spécifications à tous les niveaux. En règle générale, je ne fais rien hors de la norme avec les types de données car il peut être difficile de maintenir la route.

La rétrogradation d'un code d'appareil est une autre histoire.

Nick Tullos
la source
3
La taille des types de données est déterminée par le compilateur et non par l'architecture du processeur. Un processeur 8 bits peut avoir des entrées 32 bits, même s'il faudra plusieurs instructions pour les manipuler.
Joe Hass
bon commentaire - j'ai supprimé la première ligne en raison de la correction.
Nick Tullos du
@JoeHass: Un compilateur pour un processeur 8 bits pourrait définir intcomme 32 bits, ou même 64 pour cette question, mais je ne suis pas au courant de tous les compilateurs 8 bits existants qui en fait ne définissent intêtre supérieur à 16 bits, ou promouvoir Valeurs de 16 bits à quelque chose de plus grand.
supercat
-1

Les microcontrôleurs 32 bits consomment beaucoup plus de puissance pour un. Et nécessitent plus de circuits de support.

On ne passe pas vraiment de 32 bits à 8 bits ... Vous continuerez à utiliser les deux, souvent ensemble. L'essentiel est que vous devez utiliser (et apprendre) tout ce qui est approprié pour le travail. Apprenez ARM, car il bascule le monde intégré en ce moment et continuera de le faire. Apprenez également l'AVR ou le PIC car ce sont des contrôleurs de carte géniaux.

Vous éprouverez probablement autant de détresse lors du passage des AVR aux ARM que de ARM à x86 de toute façon, la taille du bus ne fait vraiment pas beaucoup de différence. Tout le matériel extra-avancé le fait cependant. Passer des interruptions standard à une matrice d'interruptions vectorisées avec 6 niveaux de priorité sera beaucoup plus difficile que de trouver comment compter jusqu'à quatre milliards.

Hugo
la source
4
Je ne sais pas s'il est exact de prétendre que les MCU 32 bits sont intrinsèquement plus gourmands en énergie. Au moins une gamme complète de produits ( micro-énergie ) est constituée de microcontrôleurs ultra-basse consommation, et ils sont tous basés sur un cœur ARM 32 bits.
Connor Wolf
3
Je viens de travailler sur un circuit stm32l1 qui devrait fonctionner pendant 7 ans sur un cr2032
Scott Seidman
2
Pouvez-vous justifier le commentaire selon lequel un MCU 32 bits a besoin de plus de "circuits de support"? Je pense que vous exprimez ici plusieurs opinions injustifiées.
Joe Hass
1
De plus, votre commentaire sur les interruptions vectorisées n'a pas beaucoup de sens, car vous pouvez obtenir plusieurs niveaux de priorité dans les microcontrôleurs 8 bits (voir MCU Atmel xmega, qui ont 3 niveaux de priorité), et avoir des interruptions vectorisées n'est pas pertinent lorsque chaque périphérique matériel en est équipé. propres vecteurs indépendants de toute façon.
Connor Wolf
2
J'utilise un processeur Cortex-M0 32 bits pour contrôler un chargeur de batterie intelligent pour un véhicule électrique. Il utilise une seule alimentation 3,3 V. Il a un oscillateur interne et PLL donc je n'ai même pas besoin d'un cristal. J'utilise un package DIP à 28 broches, mais je peux obtenir un Cortex-M0 dans un DIP à 8 broches si je le souhaite. Comment cela peut-il être plus complexe qu'un PIC ou AVR typique?
Joe Hass