Statique implique que la variable est à la fois isolée de ce fichier / fonction / zone de code. L'endroit où elle est définie est à la fois visible uniquement là-bas et lorsqu'elle est utilisée sur des non-globaux transforme essentiellement cette variable en une variable globale du point de vue du stockage. Une variable locale avec une définition statique signifie que je ne veux pas perdre cette valeur d'un appel de cette fonction à un autre, donc elle doit être stockée globalement pour cette fonction, normalement une variable locale est sur la pile afin que la fonction puisse être repositionnée entrant (une nouvelle copie des variables locales pour chaque entrée dans la fonction). Les globaux statiques sont donc globaux de toute façon, les locaux statiques sont locaux mais stockés avec les globaux. Dans ce que l'on appelle souvent .data, mais les chaînes d'outils peuvent avoir des noms différents. Il s'agit essentiellement de la RAM / mémoire (lecture / écriture) où vos autres globaux sont stockés ou où les variables qui sont initialisées une fois définies
int x = 7;
sont stockés. Les variables globales ou les locals statiques qui ne sont pas initialisées une fois définies
int y;
sont dans ce que l'on appelle souvent .bss. Ceci est un autre morceau de mémoire de lecture / écriture, mais cette mémoire avant de démarrer main () est mise à zéro pour vous de sorte que, par spécification ou par hypothèse, ces variables sont nulles lorsque votre programme démarre.
const est un moyen de dire que je déclare cela comme une variable en lecture seule, je ne prévois pas chaque stockage juste en lisant. Ainsi, le compilateur peut choisir (en fait, c'est le programmeur car il dicte finalement ce que fait l'éditeur de liens, laissant souvent le script de l'éditeur de liens par défaut être utilisé et ne prenant pas en charge ce travail) si cela passe en flash ou en RAM, il peut aller soit en place et travailler très bien.
Pour les microcontrôleurs et autres endroits où vous devez démarrer et démarrer à partir de la mémoire non volatile (flash / rom / etc). Tout d'abord, le programme lui-même doit être stocké dans quelque chose de non volatile. Ensuite, les éléments .data, les éléments que vous avez initialisés dans votre code lors de la définition de la variable, les éléments qui au moment de la compilation peuvent être déterminés. doit également être dans un stockage non volatile, mais ces données sont finalement en lecture / écriture, de sorte que le code d'amorçage qui s'exécute avant l'appel de main () se charge de copier les blocs .data dans la mémoire de lecture / écriture. Le code .bss ou les variables locales globales ou statiques qui ne sont pas initialisées et supposées être nulles lorsque vous démarrez, celles-ci n'ont pas besoin de stockage non volatile, juste l'emplacement et la quantité, et à partir de là, le bootstrap peut mettre à zéro cette lecture / écrire de la mémoire.
Il y a des raisons pour lesquelles nous communiquons en utilisant des termes comme .text, .data, .bss, .rodata, etc. Parce que nous voyons que les outils placent des éléments de notre programme dans ces endroits et ensuite nous peut voir où ces emplacements doivent vivre dans le stockage non volatile, puis pendant l'exécution si cela est différent. .text bien que maladroit, est notre programme, le code machine et d'autres données associées. .data sont des variables de notre programme qui sont initialisées avant de commencer à être non nulles donc elles doivent être stockées dans un stockage non volatile puis déplacées en lecture / écriture avant de les utiliser. .bss sont des variables de notre programme qui sont supposées être nulles lorsque nous démarrons, donc le montant et l'emplacement doivent être stockés en non volatile et le boostrap peut faire la remise à zéro (ou parfois ils sont simplement stockés sous forme de tas de zéros dans le flash / rom également). .rodata est parfois séparé ce sont les consts parfois les consts se trouvent dans .text, .text et .rodata sont considérés comme étant en lecture seule afin qu'ils puissent rester en flash si votre produit peut gérer cela (les flashs plus récents ont des problèmes de lecture-perturbation donc en dehors du flash sur un microcontrôleur, vous ne voulez pas nécessairement faire cela, vous devez faire attention) ou ils peuvent également être copiés sur RAM.
Ensuite, il y a les termes tas et pile, qui souvent après votre programme si nécessaire, .bss et .data consomment une certaine quantité de RAM, souvent à partir des adresses inférieures. puis le reste de ce ram est divisé en tas et pile, parfois sans ligne continue entre eux, les programmes mal conduits peuvent avoir le tas et la pile entrer en collision provoquant un crash. la pile est souvent de haut en bas et le tas est souvent de bas en haut, mais ce ne sont pas des règles strictes et rapides.
Où sont-elles sur votre tableau? eh bien, cela dépend à la fois de la puce et de la carte quant aux options, puis finalement c'est à vous, le programmeur, de décider lorsque vous contrôlez le processus de compilation et de liaison. La plupart des gens obtiennent un exemple ou une chaîne d'outils qui connaît votre système et vous laissez les paramètres par défaut. Mais vous êtes totalement responsable. Pour qu'un microcontrôleur démarre, vous devez avoir un moyen de le faire, généralement une puce flash activée ou désactivée en fonction du mcu, et les éléments non volatils mentionnés ci-dessus doivent être stockés là-bas ou dans un autre endroit non volatile. . De même, vous avez un peu de RAM, vous devez le diviser avec les éléments de lecture / écriture dont vous avez besoin, y compris la pile et le tas si vous êtes assez courageux pour l'utiliser dans un tel système (pas judicieux). Certains processeurs, la pile fait partie de la conception et vous n'avez pas à vous en soucier, d'autres vous le faites. Si vous avez plusieurs de ces choses, non volatiles ou en lecture / écriture, alors vous pouvez choisir où placer les choses.
si vous utilisez une chaîne d'outils de quelqu'un, ou si vous avez accès à d'autres. Il n'y a aucune raison de supposer qu'ils feront exactement la même chose avec votre programme avec leur script d'éditeur de liens par défaut. généralement, les chaînes d'outils fournissent des fichiers cartographiques ou d'autres moyens de voir où ils ont placé les choses pour vous.
est-il certainement possible d'avoir un système basé sur un microcontrôleur sans flash, à chaque écoute d'une souris ou d'un clavier? Certains des produits ainsi que de nombreux autres peuvent fonctionner sans de telles choses. Certains peuvent par exemple avoir dans la logique de la puce pour gérer l'énumération USB, puis le pilote du système d'exploitation pour ce produit contient le micrologiciel, télécharge le micrologiciel sur la RAM sur le périphérique, et démarre le processeur et réénumère peut-être l'usb afin que c'est maintenant une souris ou autre. tout le monde ne le fait pas mais cela se fait parfois. De même, vous pouvez avoir une autre conception où un autre matériel ou une solution télécharge le programme dans la puce / RAM avant de démarrer le processeur, ce qui donne l'impression que ce processeur n'a pas de flash. Mais vous avez toujours les mêmes concepts .text, .data, .bss et le programme que vous exécutez, que ce soit ram seulement, était encore compilé en programme, aucune donnée d'initialisation et des données d'initialisation non nulles et l'éditeur de liens devait savoir où placez ces choses dans le binaire et corrigez le code pour savoir où l'éditeur de liens a placé les variables qu'il doit utiliser.