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

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?

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.

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.

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.

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.

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.