Adressage par bus

[Linuxman99]

Bonjour ,

Dans le monde de l'électronique , il y combien de type d'adressage ,
je m'explique , lorsqu'on dit qu'un bus accède à une adresse , cela veut dire qu'il accède à une adresse dans la mémoire (RAM) pour écrire ou lire des valeur d'un composant électronique (LED par exemple) , ou un registre du processeur ?
cette dernière à déja une adresse connue dans la mémoire ?
Si ma question en bonne , comment peut-on reconnaître cette adresse , est ce relatif à chaque mémoire ?

dernière question : comment peut on savoir les adresses des entrée / sortie sur un composant électronique ?

merci à vous tous
-----

[azad]

Salut,
ta question est trop générale. Je te conseille de consulter les caractéristiques de différentes mémoires de type ancien, par exemple mémoire de 16 mots de 1 bit. Tu comprendras aisément le principe des bus adresses (4 fils dans ce cas) et bus Data (un seul fil ici), et comment on obtient le contenu de l’une des 16 cases mémoires en appliquant le bon code sur le bus adresse. Pour simplifier encore, prends plutôt une ROM, sur laquelle seule une lecture est permise, ce qui simplifie le rôle d’un troisième bus, celui de commande.
Et tu verras facilement qu’en mettant plusieurs mémoires de 1 bit de données en parallèles on peut étendre le bus Data à un nombre choisi de bits.

[mizambal]

Hello,
le bus d'adresse est externe au µP car il sert à communiquer avec les autres composants du système.
Pour ces composants adressables en mémoire, des circuits logiques de décodage d'adresse associés servent à définir les plages d'adresses qui leurs sont réservées. Si l'adresse du bus d'adresse correspond à sa plage le pin CS (Chip Select) de ce composant lui donne l’accès exclusif avec le µP ^^

une meilleure explication ici : https://fr.wikipedia.org/wiki/Chip_select

En revanche les registres mémoires sont interne aux µP donc pas besoin d'utiliser le bus externe, pas utile non plus de leur donner une adresse car à chacun des registres du µP correspond une dénomination alphanumérique (exemple sur un vieux Motorola 68000 on ne peut pas se tromper : PC, SP, A0, a1, a2, d0, d1, d2 etc..), celles qu'on utilise quand on programme en assembleur.

[jiherve]

Bonjour,
Les registres internes possèdent aussi une adresse qui peut être une partie de la plage adressable (ex Atmega) ou bien portée par un bus annexe invisible l'existence d'une mnémonique particulière ne change rien à l'affaire c'est juste un peu de confort.
JR

[A voir en vidéo sur Futura]

[invite03481543]

Bonjour,

Dans le monde de l'électronique , il y combien de type d'adressage ,
je m'explique , lorsqu'on dit qu'un bus accède à une adresse , cela veut dire qu'il accède à une adresse dans la mémoire (RAM) pour écrire ou lire des valeur d'un composant électronique (LED par exemple) , ou un registre du processeur ?
...
pour écrire ou lire des valeur d'un composant électronique (LED par exemple)

Je sens que tous les termes ne sont pas bien acquis, la question est très confuse et bien mal posée.
Un gros mélange fait entre bus, registres et adressage se fait sentir.
Par exemple ce n'est pas le bus qui accède à une adresse, le bus définissant une connexion physique, mais le µP transfère une adresse vers un périphérique via son bus d'adresse, c'est un peu différent tout de même.
On parle d'adressage pour définir la méthode qui permettra d'accéder à une adresse mémoire , donc selon où elle se trouve.

Un électronicien te dira qu'on ne lit ni écrit dans une led, un informaticien te le dira peut être ^^...

[Linuxman99]

Je pense que ma question a été mal posée , je me demande simplement , par exemple pour allumer une led , comment on connait exactement l'adresse sur laquelle on va mettre un 1 .
Est ce que chaque composant électronique a une adresse comme 0x00....

MErci

[jiherve]

Bonsoir,
L'adresse est déterminée par la façon dont le hardware a été conçu, pour de nombreux périphériques accessibles par un bus // c'est totalement arbitraire ,par contre sur des périphériques accessibles par bus série (I²C par exemple) cela peut être en partie imposé.
Dans le cas : "allumer une LED" cela dépend entièrement du hard car une LED n'a pas d'adresse intrinsèque.
JR

[Linuxman99]

Bonsoir,
L'adresse est déterminée par la façon dont le hardware a été conçu, pour de nombreux périphériques accessibles par un bus // c'est totalement arbitraire ,par contre sur des périphériques accessibles par bus série (I²C par exemple) cela peut être en partie imposé.
Dans le cas : "allumer une LED" cela dépend entièrement du hard car une LED n'a pas d'adresse intrinsèque.
JR

Merci bcp JR ,

SI j'ai bien compris le principe , les adresses en dure sont connues par le processeur sans passer par un adressage mémoire ?!
Si on essaye d'écrire dans un registre d'une carte en connaissant son adresse , quels sera le scénario entre la RAM , Processeur , Bus et registre ?!

Je pense que je confonds 2 choses , les adresses mémoires et les adresses hardware .
Merci encore

[Linuxman99]

ou plutot c'est quoi la relation entre une adresse mémoire et une adresse d'un composant hardware .
comment le transfert de donnée lors de l'écrture se fait-il ?

merci

[jiherve]

Re
Il n'y a pas de différence hormis le fait que certains périphériques puissent bénéficier d'un décodage fixe éventuellement sur un bus d'adresse dédié qui n'est pas connu de l'utilisateur. Mais pour certains µC communs(Atmega par exemple) il n'existe qu'un espace adressable et les périphériques internes y sont visibles .
En fait il n'y a aucune contrainte car le µC/µP est conçu de façon arbitraire c'est à dire au bon vouloir de son(ses en réalité) concepteur(s) (çà c'est de l’écriture inclusive mais non débile).
JR

[Linuxman99]

Re
Il n'y a pas de différence hormis le fait que certains périphériques puissent bénéficier d'un décodage fixe éventuellement sur un bus d'adresse dédié qui n'est pas connu de l'utilisateur. Mais pour certains µC communs(Atmega par exemple) il n'existe qu'un espace adressable et les périphériques internes y sont visibles .
En fait il n'y a aucune contrainte car le µC/µP est conçu de façon arbitraire c'est à dire au bon vouloir de son(ses en réalité) concepteur(s) (çà c'est de l’écriture inclusive mais non débile).
JR

Si j'ai bien compris , le processeur connait à l'avance l'adresse hardware et donc pas de décodage qui se fait au niveau de la RAM .
il reste quand même une relation entre le processeur et la ram et l'adresse hardware , car en cas d'écriture sur une LED par exemple, le contenu sera mis dans une adresse mémoire de la RAM puis transféré vers l'adresse hardware par le processeur via les bus associés , est ce exacte ?
merci

[azad]

Je crois, à te lire, que tu aurais bien besoin de faire une pause, et de faire un peu de ménage dans ce que tu as accumulé de connaissances pour en extraire des choses qui pourraient t'être utiles. Façon détournée de te dire que tu mélanges tout.

[Linuxman99]

Je crois, à te lire, que tu aurais bien besoin de faire une pause, et de faire un peu de ménage dans ce que tu as accumulé de connaissances pour en extraire des choses qui pourraient t'être utiles. Façon détournée de te dire que tu mélanges tout.

Merci azad , si tu peux me donner plus d'infos qui pourraient répondre à mes questions comme tu as l'air de mieux connaitre

[azad]

Ma remarque n’était pas une critique, mais on se rend compte que tes questions semblent posées de façon désordonnées. C’est pourquoi je t’ai conseillé plus haut de t’intéresser à l’architecture d’un système à µprocesseur. Et de préférence à un système ancien; Bien plus ancien que ceux utilisant un «*vieux*» 68000 comme je l’ai lu plus haut. Un 6800 ou un 6502 serait parfait pour débuter. Quand tu sauras cabler, ne fusse que sur le papier, un système avec des ROMs, de la Ram et quelques circuits de la famille de ton processeur, tu te rendras compte à quel point tes questions manquent de précisions.
Par exemple pour allumer une LED il suffit de se choisir une adresse libre dans l’espace addressable, de mettre sur le bus adresse et à chacun des fils du bus en question un peu d’électronique (des portes par exemple et des latch et des bascules) qui déterminera si la bonne séquence d’allumage est présente sur le bus, et tu pourras allumer ta LED. A ta charge de l’éteindre ensuite, soit avec la même adresse, soit avec une autre. Ca se serait un décodage «*fait maison*» pas très efficace mais fonctionnel. Un PIA te permettrait des choses plus intéressantes.
Mais bien évidemment il de faudra aussi t’intéresser au «*système d’exploitation*» de ta carte, lequel se résumera à ce que l’on appelait jadis un simple «*moniteur*» dans une ROM.
Bref, tu as du pain sur la planche.Et quand tu sauras faire cela, tes questions deviendront plus ciblées. C’est ce que je crois. Qu’on me corrige si je fais erreur. Et bien entendu, je parle de µprocesseur, pas de ces micro-contrôleurs avec lesquels tout est possible sans que ce qui se passe sur les bus internes soit en général, utile à connaître.

[mizambal]

le "decodage d'adresse" c'est une méthode quand même longue à expliquer, et qu'il faut avoir envie ET le temps de s'y coller mais suffit de taper "decodage d'adresse pdf" dans google tu récupères tous les cours / td / tp des bts/iut/ecole_d'ingé sur le sujet, et après à toi de faire le tri ^^

https://www.google.fr/search?q=decod...Fc2s8weWypXYCw

(et effectivement comme le remarque azad, on peut voir que ces liens renvoient souvent au thème plus général de l'architecture des ordinateurs)

[lpt1com2]

...çà c'est de l’écriture inclusive mais non débile...
JR

Excellent!

[invite03481543]

le "decodage d'adresse" c'est une méthode quand même longue à expliquer, et qu'il faut avoir envie ET le temps de s'y coller mais suffit de taper "decodage d'adresse pdf" dans google tu récupères tous les cours / td / tp des bts/iut/ecole_d'ingé sur le sujet, et après à toi de faire le tri ^^

Ou d'acheter un livre sur le sujet, google ça va bien 5mn pour trouver tous les copié collé de la planète.
Tu cherches ceux de Rodnay Zaks, y a pas mieux sur ce sujet et c'est 100% authentique et vérifié.

[Linuxman99]

Je vais essayer de cibler ma question :
pour allumer une led dans l'arduino , nous avons cette fonction :digitalWrite(pinLed1, HIGH); ou digitalWrite(pinLed1, LOW); pour l'éteindre , comment notre programme sait que pinLed1 est bien l'adresse de la pin de la Led1 .
J'essaie de comprendre le lien entre la partie programmation et la partie hardware .
Je sais que une fois le programme écrit , il est ensuite renvoyé à la RAM puis executé par le processeur .
il y a quelque chose qui m'échape ,
Désolé encore si ma question manque de rigueur

[invite03481543]

Bonjour,

ta question illustre très bien le problème d'enseigner ces bases simples avec des notions inappropriées et confusantes introduites par l'arduino et les couches haut niveau.
La pire méthode pour comprendre comment tout cela fonctionne au niveau de la couche 0.
Ce qu'il faut simplement comprendre est que pinLed1 appelle le numéro du port sur lequel ta led1 est branchée, HIGH indique que ce port sera mis à 1 pour allumer cette led... ou 0 pour l'éteindre.
Le programme le "sait" parceque pinLed1 est associé par une commande assembleur bas niveau au registre du port et au bit de ce port qui allume la led.

[Linuxman99]

Le programme le "sait" parceque pinLed1 est associé par une commande assembleur bas niveau au registre du port et au bit de ce port qui allume la led.

Quand tu dis registre du port , tu parle bien d'un registre hardware associé au port ou bien d'un registre dans une mémoire quelconque ?
Je commence mieux a cibler mes questions !

[invite03481543]

Un registre qui contiendra une valeur numérique en hexa qui va piloter l'interface hardware de commande de ce port spécifique, par exemple avec un PIC16F877A tu as le registre TRISA à l'adresse hexa 85h qui aiguillera en entrée ou en sortie ce port.
Donc à cette adresse tu envoies un mot, par exemple 10h qui activera le bit 4 => le port A4 sera en entrée ET les autres I/O du port A seront en sortie.
Il faut bien comprendre qu'un µC est une association de fonctions analogiques pilotées par des fonctions numériques (flip-flop, bascules, latch, compteur, etc)

[Linuxman99]

Un registre qui contiendra une valeur numérique en hexa qui va piloter l'interface hardware de commande de ce port spécifique, par exemple avec un PIC16F877A tu as le registre TRISA à l'adresse hexa 85h qui aiguillera en entrée ou en sortie ce port.
Donc à cette adresse tu envoies un mot, par exemple 10h qui activera le bit 4 => le port A4 sera en entrée ET les autres I/O du port A seront en sortie.
Il faut bien comprendre qu'un µC est une association de fonctions analogiques pilotées par des fonctions numériques (flip-flop, bascules, latch, compteur, etc)

donc si on revient à la fonction précedente digitalWrite(pinLed1, HIGH); cette dernière fait tout ce que tu as mentionné ?

[invite03481543]

Je n'utilise pas arduino, loin de là, mais la fonction est suffisamment explicite pour comprendre que celle-ci active ce qu'il y a sur la pin du port où est branchée la led1.
pinLed1 et HIGH sont les arguments de cette fonction.
DigitalWrite => écriture numérique
pinLed1: port où est branchée led1
HIGH pour 1
LOW pour 0

Pour diriger le port tel que je l'ai décrit plus haut il faut écrire au préalable:
pinMode(pinLED1, OUPTUT)

[Linuxman99]

aussi , le nombre de périphérique qui pourrait être connecté à un processeur doit être connu à l'avance , car on je me demande si on veut allumer 100 led chacune connecté sur un port particulier ?!

[invite03481543]

Ce qui en C standard s'écrit de manière extrêmement compliquée :

sbit led1                       at RC2_bit;
sbit led1_Direction        at TRISC2_bit;
.
.
.
led1 = 1;

On voit ici tout l'intérêt de l'arduino....

[invite03481543]

aussi , le nombre de périphérique qui pourrait être connecté à un processeur doit être connu à l'avance , car on je me demande si on veut allumer 100 led chacune connecté sur un port particulier ?!

Pas sur de bien comprendre ta question.
Il vaut mieux savoir à l'avance ce que l'on veut faire quand on choisit un µC.
Tu dois par exemple faire le bilan des ressources nécessaires à ton projet (nombre d'I/O, nombre de compteurs, nombre d'entrées analogiques, I2C, UART, PWM, etc).
Après tu choisis un candidat parmi les centaines de µC disponibles.

[invite03481543]

Tu n'as besoin d'accéder ou manipuler certains registres que lorsque tu travailles en bas niveau (en assembleur), avec un langage haut niveau ces fonctions toutes faites font la liaison entre ton code et le bas niveau matériel à ta place.
Et te masquera ce qui ne fonctionne pas si il y a un bug un jour dans une de ces fonctions...

[Linuxman99]

donc de façon général je pense qu'il faudrait sur l'arduino se contenter de ce que le kit nous permet de faire sans se soucier des registres TRISA ou autres ,
moi de ma vue de débutant , je pensais tujours que pour porgrammer un pic ou un microprocesseur , on programme tout seimplement le programme , on le compile et on l'envoie pour execution sur le proc sans se soucier de quoique registre interne .

est ce qu'il y a toujours un registre sur le quel on doit écrire ou lire peut importe la technologie utiliser pour activer un périphérique ? et ce registre ce n'est pas u registre de la RAM mais plutot du controleur ou processeur lui même ?

Merci

[azad]

Un périphérique est un dispositif qui est à l’écoute de l’espace mémoire auquel il est associé. En fonction de la tâche qu’il a à faire, cet espace mémoire peut très bien n’être qu’un simple Bit. Ainsi un seul octet mémoire peut servir à commander via 8 périphériques, jusqu’à 8 Leds. Ce n’est donc pas le nombre de périphériques qui est primordial, mais la taille de la mémoire allouée à ces périphériques. Dans ton exemple simple des 100 Leds, treize octets suffisent pour les allumer toutes et indépendamment les unes des autres. Tu auras 100 périphériques effectivement disponibles si l’ électronique associée est câblée bien sûr. Mais ce qui compte le plus ce sont les treize octets que tu leur a alloués. Si tu décidais d’utiliser des Leds 3 couleurs, sans changer la taille du buffer (trois octets) tu ne disposerais plus que de 33 périphériques 3 couleurs.

[Linuxman99]

Un périphérique est un dispositif qui est à l’écoute de l’espace mémoire auquel il est associé. En fonction de la tâche qu’il a à faire, cet espace mémoire peut très bien n’être qu’un simple Bit. Ainsi un seul octet mémoire peut servir à commander via 8 périphériques, jusqu’à 8 Leds. Ce n’est donc pas le nombre de périphériques qui est primordial, mais la taille de la mémoire allouée à ces périphériques. Dans ton exemple simple des 100 Leds, treize octets suffisent pour les allumer toutes et indépendamment les unes des autres. Tu auras 100 périphériques effectivement disponibles si l’ électronique associée est câblée bien sûr. Mais ce qui compte le plus ce sont les treize octets que tu leur a alloués. Si tu décidais d’utiliser des Leds 3 couleurs, sans changer la taille du buffer (trois octets) tu ne disposerais plus que de 33 périphériques 3 couleurs.

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 ?