ARM MCU prend en charge les petits Endian et Big Endian. Cependant, lorsque les microcontrôleurs conçus de la conception, quand ils utilisent un microprocesseur de bras et y ajouter des périphériques, ils soutiennent soit grand Endian, soit peu d'Endian. Donc, ma question est de savoir comment le fabricant du conseil d'administration de STM32, TI décide s'il souhaite supporter un peu ou un grand Endian. Autant que je sache, le microprocesseur de bras soutient la petite Endian et Big Endian.
3 Réponses :
C'est complètement subjectif.
Les termes gros Endian et Little Endian sont extraits des voyages de Livre Gulliver, où deux nations combattent une guerre féroce et sanglante basée sur le désaccord sur le cas si on devrait éclore un œuf sur le "gros" côté ou le "petit" côté. C'est-à-dire qu'ils se battaient sur quelque chose de complètement inutile.
Dans le monde informatique dans les années 1970-80, le grand camp d'Endian consistait en mesure de Motorola et de IBM, et le petit camp d'Endian consistait en évidence d'Intel. Tous les autres fabricants ont dû choisir de chaque côté.
Si surtout, il est cueilli par la tradition.
En ce qui concerne le bras spécifiquement, tous les armes cortex sont en pratique peu d'Endian. Même Freescale, ancienne Motorola, a choisi peu d'Endian pour leur famille Kinetis. Il existe cependant divers autres architectures 32 bits qui utilisent Big Endian, y compris, je crois que des armes de pré-cortex.
important, "Endianess du réseau" est presque toujours grand Endian, également hors de la tradition. Mais cela a une raison objective et pratique réelle, nommément calculs de CRC. Afin de créer une calculatrice CRC dans la logique numérique pure avec Xor Gates, les données doivent être transmises par MS Byte d'abord. Il est aujourd'hui rare de mettre en œuvre CRC à l'aide de portes numériques, mais c'est la raison historique.
L'écosystème logiciel pour ARM Cortex MCU est plus ou moins exclusivement petit-Endian. Il serait peu probable que quiconque choisisse d'utiliser de gros Endian exclusivement ou même mélangé-endian sans une raison spécifique de très bonne application. Donc, le choix est normalement simple et je doute que les concepteurs y réfléchissent du tout.
Contrairement à d'autres implémentations de bras, Cortex-M MCU ne prend pas en charge le changement de «sur la mouche» de l'endansion et le choix de l'endansion est fixé par les fournisseurs de silicium. Tous populaires (et peut-être même non populaires) Cortex-M MCU implémente Little Endian, c'est donc la réponse pratique.
Petite Endian est plus facile à cartographier un flux de caractères octets / ascii en mémoire. Alors, peut-être que c'est une raison pour laquelle il est plus populaire.
Le choix de l'endianness est assez immatériel. Si vous écrivez un code autonome dans une langue de haut niveau qui n'échange pas de données avec quelqu'un d'autre, cela n'a pas vraiment d'importance que vous choisissez. Même si vous devez échanger des données, vous encapsuleriez généralement l'accès des données dans certaines fonctions de faible niveau, de sorte que l'endansion est toujours trop négligeable.
"La petite Endian est plus facile à mapper un flux de caractères octets / ascii en mémoire. Alors, peut-être que c'est une raison pour laquelle il est plus populaire." Eh? Endianess ne s'applique même pas à un flux d'octets, alors qu'est-ce que vous parlez même?
@Lundin: Endianness d'octet. C'est le problème du nuxi. I.e. Sur une petite machine Endian, si vous lisez les octets en mémoire, il se lit comme unix, mais si vous lisez les octets de mémoire dans l'ordre sur une grande machine Endian, elle se lit comme Nuxi. Selon vous, quelle endianité s'applique-t-elle?
"Mais si vous lisez les octets de mémoire dans l'ordre sur une grosse machine Endian, il se lit comme Nuxi" c'est un non-sens complet. La seule façon de se bousiller comme vous décrivez est si vous stockez des paires de caractères en 16 bits mots, pas d'octets . Mais pourquoi une personne saintte ferait-elle cela? Et si vous l'avez fait, vous obtiendrez Nuxi sur une machine petite machine machine. Une grosse machine Endian stockera toujours les caractères "UNIX" comme u = adresse la plus basse, peu importe s'il s'agit d'un tableau de caractères de caractère ou d'un uint32_t. Avez-vous déjà travaillé avec de grandes machines Endian?
@Lundin, vous n'avez vraiment pas entendu parler du problème Nuxi? Ceci est connu dans les années 1970. S'il vous plaît juste Google "NUXI problème". Et oui, j'ai écrit C compilateurs C pour 68k, VAX-11, PA-RISC, et ...
Premier lien: "(problème de Nuxi) fait référence au problème de transfert de données entre les machines à l'ordre différent. La chaîne" UNIX "peut ressembler à" NUXI "sur une machine avec un sexe d'octet différent (par exemple, lors du transfert de données d'un Little-Endian à un Big-Endian, ou vice-versa). Nuxi Problème - Catb.org www.catb.org/jargon/html/n/nuxi-problem.html "
Je vois la confusion potentielle: nous sommes probablement dans un accord violent. Vous pensez probablement que lorsque j'ai utilisé le terme "flux d'octets", je voulais écrire les octets un octet à la fois. J'aurais dû être plus précis de dire "Écrire un flux d'octets, quel que soit le type de données utilisé", par exemple. Vous pouvez écrire une séquence d'octets, une séquence de 16 bits ou une séquence de 32 bits (en supposant que la machine est une petite machine endiane "pure") et les résultats sont identiques. Il est donc "plus facile de mapper un flux de caractères octets / ascii en mémoire", comme j'ai écrit.
Votre problème "Nuxi" est probablement juste le petit problème de Big VS Endian. Mais il n'existe aucun système dans le monde (que je connaisse) où les caractères ASCII ne sont pas stockés avec la première lettre à l'adresse la plus basse et la dernière lettre de l'adresse la plus élevée. Et donc il n'existe aucun système connu dans le monde qui imprimerait l'ASCII String "Unix" comme "nuxi" .
@LUNDIN, ce n'est pas entièrement académique, imaginez que vous écrivez un programme pour que vous soyez machine, et vous écrivez correctement une chaîne de caractères ASCII, par exemple. Unix comme des octets. Maintenant, si vous exécutez le programme sous un débogueur et affichez la mémoire sous forme de mots 16 bits ou 32 bits (probablement la valeur par défaut dans une vue de mémoire), vous verriez le contenu affiché comme équivalence de NUXI.
Pourquoi voudriez-vous jamais voir la mémoire comme des mots dans un débogueur, si ce n'est pas ce qui est stocké à cet endroit de la mémoire, sans parler de ce que vous souhaitez voir? Cela ressemble à un mauvais programmeur utilisant un mauvais débogueur Plus que toute autre chose. Je ne pense pas avoir jamais utilisé un débogueur aussi mauvais que j'ai utilisé au moins 30 autres différents, y compris de très mauvais. Alors quel débogueur parlez-vous, plus précisément?
Au lieu de dériver, vous voudriez peut-être répondre à "pourquoi voudriez-vous jamais voir la mémoire comme des mots dans un débogueur". Vous faites glisser dans ce "problème nuxi" mais vous pouvez apparemment pas illustrer un exemple de quand cela se produira.
@Lundin, il ne dérive pas hors sujet. Si vous avez utilisé un débogueur qui montre la mémoire comme je l'ai dit, et il y a beaucoup plus de primitif, c'est ce que vous voyez. Je sais que tu veux "gagner". C'est très bien. Vous gagnez. Tout le monde peut savoir Google "Nuxi Problème" de savoir que c'est un vrai problème. Si vous ne l'avez jamais rencontrée, bon pour vous.
Et honnêtement, ce n'est pas si difficile d'imaginer. Vous avez plusieurs variables: struct {int anarray [4]; Char String [5]} x = {{1,2,3,4}, {"Unix"}}; Ensuite, vous envisagez la fenêtre de la vue de la mémoire, vous ne vancez pas la variable en soi, il suffit de regarder l'adresse (par exemple, un débogueur primitif qui n'affiche pas la structure), puis bam, vous voyez Nuxi sur une machine.
Non! Vous recherchez UNIX puisque A être la machine stocke les données comme U, N, I, X dans cet ordre. Comme une machine de la machine. Lorsque je suis Google "Nuxi Problème", je ne reçois que de génériques, de mauvaises explications sur la différence d'être et le, qui à nouveau ne s'applique pas aux chaînes. Le fait que vous continuiez à insister que l'ordre d'octet serait d'abord d'abord que vous ne comprenez même pas lequel vous ne comprenez même pas celui qui est grand Endian et celui qui est petit Endian.
Pour vous épeler à vous, cet exemple goodbolt.org/z/ic21vs imprimera l'hex correspondant à "Xinu" sur une machine Le Machine et Hex correspondant à "Unix" sur A être machine. Afin d'obtenir NUXI, il faut faire quelque chose d'extraordairement étrange, comme de stocker des caractères dans des séquences de mots de 16 bits, puis d'imprimer sur une petite machine Endian.
@Lundin, la question est que vous envisagez uniquement de développer un développement indigène. J'écris C cross compilateurs et faisons beaucoup de développement de firmware pour différents micros. Il est tout simplement possible que je n'ai que le Micros test planches actuellement (ARM Cortex-M et AVRS), mais j'écris à écrire un micrologiciel pour 68HC12 et 68HC11, soyez micros. Les debuggers exécutant sur PC par la mémoire d'affichage par défaut au format Le format. Les bons vous permettent de cocher une boîte pour basculer pour être au format si la cible fonctionne en mode, mais il y a beaucoup d'anciennes qui ne le font pas. Voila, vous avez votre nuxi juste là.
Tous les debuggers pour HC12 // HC08 que j'ai utilisé n'avaient pas de telles bizarreries particulières. Pas de codewarrior, pas uni, pas cosmique, pas Lauterbach, pas PE Micro. Alors quel débogueur, exactement? Et encore des cordes ne dépendent pas de l'endianesse ...
Incorrect - une partie du soutien des armes.