Adressage par bus

[PA5CAL]

Bonjour

En fait, quand tu écris digitalWrite(pinLed1, HIGH); dans ton programme en C, c'est toi qui dois avoir défini la valeur de pinLed1 pour pouvoir commander la sortie sur laquelle tu as branché la led. Cette valeur est transcrite par la bibliothèque logicielle Arduino pour adresser le bit d'un port matériel, la position du bit et l'adresse du port étant donnés dans un fichier de définition (.h) correspondant au modèle d'Arduino sélectionné au moment de la compilation.

Reprenons du début.

L'adressage est un terme général qui désigne la sélection d'un élément particulier du système dans le but de l'impliquer dans une opération. L'adressage peut être réalisé de nombreuses façons :


• Un élément peut être adressé de façon implicite. Il n'a pas d'adresse à proprement parler, sa sélection étant déterminée du seul fait de l'opération effectuée. Matériellement, cette sélection est réalisée par l'application d'un signal logique direct sur le circuit électronique.

Par exemple, sur un ATmega, l'instruction machine CLI (ou cli() en langage C) adresse de façon implicite le bit I du registre d'état SREG pour le remettre à zéro afin d'interdire la prise en compte des interruptions matérielles.


• Un élément peut faire partie d'un ensemble dans lequel il est désigné par un numéro d'ordre. L'ensemble auquel il appartient est un espace d'adressage, et son numéro d'ordre est son adresse dans cet espace.

Tous les éléments d'un système n'appartiennent pas forcément au même espace d'adressage, et un élément peut appartenir à plusieurs espaces d'adressage en même temps.

Par exemple, sur un ATmega, on trouve un espace d'adressage pour la mémoire programme (Flash), un autre pour la mémoire EEPROM, et un autre dans lequel sont regroupés les registres de travail, les registres d'entrée-sortie et la mémoire vive (SRAM). Ces espaces sont totalement indépendants les uns des autres.

Mais les registres d'entrée-sortie appartiennent également à un espace d'adressage particulier utilisé par certaines opérations. Le registre PORTD de l'ATmega328P (qui contrôle l'état des broches 0 à 7 de l'Arduino Uno/Nano/Pro/Mini) a pour adresse 0x2B dans l'espace d'adressage partagé avec la SRAM et utilisé notamment par les instructions machine STx et LDx, et il a pour adresse 0x0B dans l'espace d'adressage utilisé par les instructions machine OUT, IN, SBIx et CBI.

C'est le type d'opération qui détermine quel espace d'adressage est concerné, et ce sont les paramètres de cette opération qui déterminent l'adresse de l'élément impliqué, au moyen d'un mode d'adressage (un calcul d'adresse réalisé à partir de ces paramètres) qui peut être assez variable (immédiat, direct, indirect, indexé, etc.). Je ne développerai pas plus cette partie, car on trouve de nombreux articles détaillés sur le net à ce sujet, par exemple ici.


• Il existe d'autres façons de sélectionner un élément, plus complexes ou mettant en œuvre des moyens moins classiques, comme par exemple au travers d'un adressage par le contenu. Mais cela ne présente pas d'intérêt dans cette discussion si tu te limites aux micro-contrôleurs et aux systèmes numériques traditionnels.


Le développeur du programme doit donc accéder à l'élément qu'il souhaite manipuler :
- soit en utilisant son adresse matérielle dans l'espace d'adressage déterminé par le type d'opération (d'instruction machine) réalisée,
- soit en utilisant sa désignation logique, déterminée par une définition et/ou un mécanisme logiciel fournis par le langage de programmation ou par une bibliothèque logicielle prévue à cet effet.
-----

[invite03481543]

Il n'est pas toujours indispensable de savoir à quelle adresse se trouve un registre, tout dépend de qui développe le programme et surtout avec quels outils logiciels.
De nos jours un pur softeux travaille sur du code haut niveau et traduit en code des fonctionnalités que d'autres ont spécifié sur un document détaillé (algorithmes, synoptique fonctionnel, etc).
On appelle ça "pisser du code".
De plus en plus on fait appel à des logiciels pour cracher le code final, après avoir coché des cases et définit un scénario de fonctionnement dans un simulateur...
Ces logiciels sont sensés être certifiés pour certains domaines particuliers qui intègre des macros prédéfinies et durcies (aéronautique, automobile, etc).


Pour pouvoir traiter au plus vite les taches on utilise que de la RAM.

[Linuxman99]

Quel est la règle générale pour faire communiquer :
Un microcontroleur / microprocesseur avec un périphérique vis à vis de la RAM , vis à vis de registres internes .

merci

[invite03481543]

Pour ne pas créer de réponses croisées et embrouiller l'explication je laisse PA5CAL continuer, il est bien parti.
@+

[azad]

Je suis encore perdu la ! c'est le processeur qui écrit une valeur sur le port pour activer les leds ou c'est la mémoire qui demande au processeur d'écrire une valeur sur le port sortie ?

Le processeur écrit une adresse sur le bus adresse à l’aide d’une instruction qui comporte l’adresse effective ET la valeur à écrire à cette adresse. Mais la présence d’une Ram à cette adresse n’est pas une obligation. Quand le champ adresse est atteint, c’est la valeur contenue dans l’instruction qui se trouve placée sur le bus Data. Et si tes périphériques sont bien configurés (en terme de décodage) alors ils vont être actionnés et faire leur travail. Pas donc besoin de Ram. Mais bien entendu, je joue là sur des mots, car l’ensemble de l’électronique associée à ton périphérique se comporte comme une Ram, il y a là des bascules, des latch, du tri-state souvent et c’est quasiment de la RAM.
Maintenant il convient de savoir de quoi tu souhaites parler : micro processeur, ou micro contrôleur. Sans cette précision, la discussion n'a aucun sens !

[PA5CAL]

...

En pratique, le moyen le plus direct pour allumer la led L (broche 13) d'un Arduino Uno (qui contient un ATmega328P) est d'écrire dans le programme le code :

  PINB |= (1<<5);
  PORTB |= (1<<5);

La première ligne positionne à 1 le bit 5 du registre PINB qui contrôle la configuration (entrée=0 ou sortie=1) de la broche PB5 du micro-contrôleur, qui est reliée à la broche 13 sur la carte Arduino Uno. La seconde ligne fait de même avec le bit 5 du registre PORTB qui contrôle l'état de sortie (LOW=0 ou HIGH=1) de la broche PB5.

Une fois compilé, ce code va produire les instructions machine suivantes :

  SBI  0x03, 5
  SBI  0x05, 5

Le mnémonique SBI signifie « Set Bit in I/O Register ». Le premier paramètre est l'adresse du registre visé dans l'espace d'adressage des registres d'entrée-sortie. Le second paramètre est le numéro du bit visé.

Chacune de ces deux opérations utilise 1 mot de mémoire programme (Flash 16 bits), dure 2 cycles d'horloge système, et ne réclame aucune mémoire vive.


Mais ce code n'est pas portable, car le registre et le bit permettant d'accéder à la led L sont parfois différents sur les autres Arduinos.

Par exemple, sur l'Arduino Leonardo, la led L et la broche 13 sont connectées à la broche PC7. Dans ce cas, on devrait écrire dans le programme le code :

  PINC |= (1<<7);
  PORTC |= (1<<7);

Arduino a résolu ce problème de compatibilité en proposant les fonctions pinMode() et digitalWrite() et une normalisation de la numérotation des broches des cartes. On peut alors écrire dans le programme :

const int pinLed = 13;

puis :

  pinMode( pinLed, OUTPUT );
  digitalWrite( pinLed, HIGH );

Au final, ces quelques lignes réalisent la même chose que précédemment, mais en exécutant un nombre beaucoup plus important d'opérations et en utilisant beaucoup plus de mémoire programme et de mémoire vive. En effet, dans chacune des fonctions, on commence par vérifier si les paramètres passés ont bien un sens, on retrouve l'adresse du registre et le numéro du bit correspondants à la valeur de pinLed à l'aide de tables de transcription stockées en mémoire programme et spécifiques au modèle d'Arduino sélectionné, on désactive le timer qui pourrait contrôler la sortie en mode PWM, puis on modifie le bit comme souhaité (OUTPUT=1, HIGH=1).

Ce n'est certainement pas la solution la plus optimale, mais c'est celle choisie par le projet Arduino, dont le but est surtout d'offrir un système de développement simple et fonctionnel accessible à des débutants.

[Linuxman99]

merci , ça doit être pareil entre microcontrôleur et microprocesseur ?

[azad]

Tout à fait. Comme un Mondrian ressemble à un Léonard de Vinci !

[PA5CAL]

Dans l'exemple que je viens de donner ci-dessus, l'espace d'adressage des registres d'entrée-sortie de l'ATmega328P fonctionne comme celui d'une RAM, mais avec des adresses spécifiques à cet espace (pour rappel, les mêmes registres sont accessibles à des adresses différentes dans l'espace d'adressage incluant les registres de travail et la SRAM). On peut également considérer que l'adressage du bit à l'intérieur du registre repose sur le même principe (la valeur 5 dans l'instruction SBI sélectionnant le bit 5 pour l'opération).

Toutefois, on peut aussi avoir affaire à un adressage matériel implicite qui ne repose pas sur l'envoi de la valeur d'une adresse sur un bus. Le séquenceur au cœur du micro-contrôleur ou du micro-processeur peut en effet directement sélectionner un bit, un registre ou un porte logique lors d'une opération.


On ne peut donc en rester qu'aux généralités tant qu'on ne discute pas précisément d'un cas particulier. Mais traiter un cas particulier ne permet pas non plus de connaître l'ensemble des situations existantes.

Il vaudrait donc mieux que tu précises ta question (... en évitant d'y inclure une partie de la réponse, qui apparaît d'ailleurs comme assez inexacte).

[Linuxman99]

...

En pratique, le moyen le plus direct pour allumer la led L (broche 13) d'un Arduino Uno (qui contient un ATmega328P) est d'écrire dans le programme le code :

  PINB |= (1<<5);
  PORTB |= (1<<5);

La première ligne positionne à 1 le bit 5 du registre PINB qui contrôle la configuration (entrée=0 ou sortie=1) de la broche PB5 du micro-contrôleur, qui est reliée à la broche 13 sur la carte Arduino Uno. La seconde ligne fait de même avec le bit 5 du registre PORTB qui contrôle l'état de sortie (LOW=0 ou HIGH=1) de la broche PB5.

Une fois compilé, ce code va produire les instructions machine suivantes :

  SBI  0x03, 5
  SBI  0x05, 5

Le mnémonique SBI signifie « Set Bit in I/O Register ». Le premier paramètre est l'adresse du registre visé dans l'espace d'adressage des registres d'entrée-sortie. Le second paramètre est le numéro du bit visé.

Chacune de ces deux opérations utilise 1 mot de mémoire programme (Flash 16 bits), dure 2 cycles d'horloge système, et ne réclame aucune mémoire vive.


Mais ce code n'est pas portable, car le registre et le bit permettant d'accéder à la led L sont parfois différents sur les autres Arduinos.

Par exemple, sur l'Arduino Leonardo, la led L et la broche 13 sont connectées à la broche PC7. Dans ce cas, on devrait écrire dans le programme le code :

  PINC |= (1<<7);
  PORTC |= (1<<7);

Arduino a résolu ce problème de compatibilité en proposant les fonctions pinMode() et digitalWrite() et une normalisation de la numérotation des broches des cartes. On peut alors écrire dans le programme :

const int pinLed = 13;

puis :

  pinMode( pinLed, OUTPUT );
  digitalWrite( pinLed, HIGH );

Au final, ces quelques lignes réalisent la même chose que précédemment, mais en exécutant un nombre beaucoup plus important d'opérations et en utilisant beaucoup plus de mémoire programme et de mémoire vive. En effet, dans chacune des fonctions, on commence par vérifier si les paramètres passés ont bien un sens, on retrouve l'adresse du registre et le numéro du bit correspondants à la valeur de pinLed à l'aide de tables de transcription stockées en mémoire programme et spécifiques au modèle d'Arduino sélectionné, on désactive le timer qui pourrait contrôler la sortie en mode PWM, puis on modifie le bit comme souhaité (OUTPUT=1, HIGH=1).

Ce n'est certainement pas la solution la plus optimale, mais c'est celle choisie par le projet Arduino, dont le but est surtout d'offrir un système de développement simple et fonctionnel accessible à des débutants.

Merci pour les explications
la mémoire RAM a un rôle particulier dans l'adressage aussi ?
Car si on configure un registre particulier (lié à un port / pinoche) et on écrit sur ce registre 1 ou 0 , l'utilisation de la RAM du microcontroleur / microprocesseur intervient ou plus concrètement (est ce juste lors des calculs de valeurs par le processeur avec la UAL ? ) ou une lors de l'envoie d'une image de notre programme en C est qui sera transféré vers la RAM pour execution tout comme le concept de démarrage d'un OS (Disque dur - RAM-Processeur )

[PA5CAL]

la mémoire RAM a un rôle particulier dans l'adressage aussi ?

Dit comme ça, la question n'a pas de sens.

La seule véritable relation qu'on peut trouver entre « RAM » et « adressage », c'est qu'on peut adresser un octet d'une RAM. Rien de plus.

La RAM (Random Access Memory = mémoire à la quelle il est possible d'accéder de façon aléatoire) n'est pas un élément obligatoire dans un système de traitement informatisé, dès lors qu'il existe d'autres structures pour mémoriser l'information.

Par exemple, il est tout-à-fait possible de créer un programme fonctionnel pour un ATmega qui n'utilise pas du tout la RAM. Le programme est de toute manière intégralement stocké en mémoire Flash (sur les micro-contrôleurs AVR il ne peut pas être exécuté depuis la RAM), et il peut n'utiliser que les registres de travail pour les calculs et les registres d'entrées-sorties pour les échanges avec l'extérieur.

[jiherve]

Bonsoir,
sur les petits µC* le code tourne en mémoire morte (Flash) par contre la ram peut être utilisée si il y a des calculs complexes à effectuer et que les registres disponibles ne suffisent pas ou si l'on appelle et passe des paramètres à un sous programme , utilisation de la pile (stack) qui est forcement en RAM; Et la RAM n'intervient pas dans le décodage d'adresse sauf dans certains cas qu'il est inutile d'aborder ici et maintenant vu le niveau de confusion.
* sauf le Propeller qui tourne toujours en RAM.

JR

[Linuxman99]

En plus si j'ai bien compris (je l'èspère) :

On adresse des registres afin de piloter des périphériques tout simplement qui sont connectés physiquement via des ports , mais l'activation de ses ports se fait en activant ou pas les registres associés .

Les registres a activer peuvent être ceux de la RAM / SRAM / EEPROM , selon le type d'opération souhaitée .

les registres sont lus ou écrits par l'intermédiaire de bus connectés physiquement au processeur / microcontrôleur .

NB : Je pensais avant que le bus (spi ) par exemple permettais de faire circuler du courant directement vers le périphérique à piloter ! je me trompais

[jiherve]

Re
regarde là :http://www.technologuepro.com/microc...r/microavr.htm
il y a les boyaux d'un µC de la famille Atmel et des explications qui eclaireront peut etre ta lanterne.
JR

[PA5CAL]

On adresse des registres afin de piloter des périphériques tout simplement qui sont connectés physiquement via des ports , mais l'activation de ses ports se fait en activant ou pas les registres associés .

C'est l'une des utilisations possible des registres (on parle alors de registres d'entrée-sortie). Mais tous les registres ne servent pas qu'à ça.

Les registres a activer peuvent être ceux de la RAM / SRAM / EEPROM , selon le type d'opération souhaitée .

Gnniii !!! Disons que la formulation est suffisamment tendancieuse pour que je m'abstienne de confirmer. Voir plus bas.

les registres sont lus ou écrits par l'intermédiaire de bus connectés physiquement au processeur / microcontrôleur .

Oui, le plus souvent, mais pas toujours.


Un registre est une mémoire regroupant plusieurs bits, modifiables ou pas (lecture seule), lisibles ou pas (écriture seule).

Une RAM (ou SRAM = Static RAM) doit être vue comme un ensemble de registres appartenant à un même espace d'adressage, qui ne servent qu'à être écrits et lus afin de conserver provisoirement des données, ou du code exécutable (sur certains systèmes mais pas tous). En principe son contenu est perdu après chaque mise hors tension du système.

Une mémoire Flash doit également être vue comme un ensemble de registres appartenant à un même espace d'adressage, mais destinés principalement à conserver durablement du code exécutable ou des données, même après une coupure d'alimentation du système. La lecture de son contenu est similaire à celle d'une RAM, mais son écriture implique la mise en œuvre de procédés matériels et logiciels particuliers.

La mémoire EEPROM est similaire à une mémoire Flash, mais la technologie et les performances sont différentes, et elle sert essentiellement à stocker des données, rarement du code exécutable.

Néanmoins, traditionnellement le terme de « registre » n'est pas employé pour désigner ces mémoires. Il est plutôt réservé dans le cas de registres isolés, regroupés en petits nombre ou destinés à des usages particuliers (contrôle de circuits, réception de résultats de calculs, ...).



Un bus est un dispositif de transmission de données partagé entre plusieurs composants d'un système . Lorsqu'il n'y a pas de fonction de partage, il ne s'agit pas d'un bus mais juste d'une liaison numérique.


Les registres et les mémoires d'un système peuvent être internes ou externes au micro-contrôleur ou au micro-processeur.

Lorsqu'ils sont externes, on y accède en principe à l'aide d'un ou plusieurs bus externes. Selon le cas, on peut se retrouver avec des bus de contrôle, d'adresse et de données séparés (bus parallèle des micro-processeurs classiques), avec un bus unique sur lequel les commandes, les adresses et les données circulent consécutivement (bus série I2C, USB, etc.), ou dans une situation intermédiaire (bus SD, liaisons SPI, etc.).

Les bus externes sont souvent placés sous le contrôle de registres internes spécifiques du micro-contrôleur, qui peuvent être normalement accessibles ou bien totalement inatteignables depuis le programme exécuté. Parfois ils fonctionnent sans aucun registre dédié (autre que ceux stockant l'adresse et la donnée), seulement à l'aide de circuits logiques de décodage et de multiplexage pilotés par le séquenceur du micro-contrôleur ou du micro-processeur.

En principe, l'accès aux mémoires internes se fait systématiquement via des bus parallèles (adresse+donnée), éventuellement contrôlés par des registres internes dédiés. L'accès aux registres internes peut être réalisé, selon le cas, via des bus comme pour les mémoires, ou bien sans bus d'adresse (adressage implicite).

En fait, il faut considérer les bus comme des composants à part entière d'un système qui, selon les besoins fonctionnels à satisfaire, peuvent être présents ou absents, et fonctionner automatiquement ou sous le contrôle du programme via des registres.

[jiherve]

Re,

En fait, il faut considérer les bus comme des composants à part entière d'un système qui,, selon les besoins fonctionnels à satisfaire, peuvent être présents ou absents, et fonctionner automatiquement ou sous le contrôle du programme via des registres.

çà c'est ben vrai surtout avec les dernières architectures ARM en particulier.
JR

[Linuxman99]

Bonsoir,
sur les petits µC* le code tourne en mémoire morte (Flash) par contre la ram peut être utilisée si il y a des calculs complexes à effectuer et que les registres disponibles ne suffisent pas ou si l'on appelle et passe des paramètres à un sous programme , utilisation de la pile (stack) qui est forcement en RAM; Et la RAM n'intervient pas dans le décodage d'adresse sauf dans certains cas qu'il est inutile d'aborder ici et maintenant vu le niveau de confusion.
* sauf le Propeller qui tourne toujours en RAM.

JR

On nous a tujours expliqué que le code tourne sur la RAM ? je me trompe encore ?! il existe sur le disque dur ou la flash mais une copie est transféré à la RAM au démararge

[PA5CAL]

On nous a tujours expliqué que le code tourne sur la RAM ? je me trompe encore ?! il existe sur le disque dur ou la flash mais une copie est transféré à la RAM au démararge

C'est souvent vrai, mais pas toujours.

C'est notamment le cas sur les plus gros systèmes, tels que les PC ou les SoC.

Mais sur les petits microcontrôleurs AVR (Arduinos Uno, Mega, Leonardo, etc.), le programme ne peut être stocké et exécuté qu'en mémoire Flash interne. La mémoire vive ne peut contenir que les données que le programme y aura placées. Cela limite dans une certaine mesure les modifications inopinées du programme, et réduit la quantité de mémoire embarquée, le coût et la consommation électrique du circuit.

[jiherve]

Bonjour,
en complément même avec un processeur capable de faire tourner du code en RAM il peut être intéressant de ne pas le faire et donc de tourner en ROM(flash ou autre) pour des raisons de sécurité car ces mémoires sont tout de même moins sensibles(tout du moins le furent elles ) aux radiations.
JR

[Linuxman99]

Merci à vous les amis