[RESOLU] lire état d'une sortie digitale

Artouste:

john_lenfr:
Celui-ci?: http://arduino.cc/en/Hacking/Atmega168Hardware

Digital pin13 = PB5 ? Mais il y a aussi un PD5?

Je comprends rien, pas très clair dans ma tête…

ça depend de ta carte arduino,
dans l’exemple La led13 est sur le connecteur 13 de l’arduino qui est relié par routage PCB sur la pin 19 de l’atmel 168 qui est le bit 5 du PORTB :grin:

Ok, cette fois ci j’ai tout compris.

Si je suis le schéma et les indication de la page “Port Manipulation” on aurait:

PORTD maps to Arduino digital pins 0 to 7

PORTD 0b00000001 (1 en DEC)=>pin 0
PORTD 0b00000010 (2 en DEC)=>pin 1
PORTD 0b00000100 (4 en DEC)=>pin 2
PORTD 0b00001000 (8 en DEC)=>pin 3
PORTD 0b00010000 (16 en DEC)=>pin 4
PORTD 0b00100000 (32 en DEC)=>pin 5
PORTD 0b01000000 (64 en DEC)=>pin 6
PORTD 0b10000000 (128 en DEC)=>pin 7

PORTB maps to Arduino digital pins 8 to 13

PORTB 0b00000001 (1 en DEC) =>pin 8
PORTB 0b00000010 (2 en DEC)=>pin 9
PORTB 0b00000100 (4 en DEC)=>pin 10
PORTB 0b00001000 (8 en DEC)=>pin 11
PORTB 0b00010000 (16 en DEC)=>pin 12
PORTB 0b00100000 (32 en DEC)=>pin 13
PORTB 0b01000000 =>crystal pin not usable
PORTB 0b10000000 =>crystal pin not usable

Dans notre exemple on a bien demandé l’état en faisant du PORTB sur la pin 13, ce qui nous a bien renvoyé 32 en DEC soit 0b00100000
:grin:

Un graphique qui peut être bien utile pour manipuler les ports : http://arduino.cc/en/Hacking/PinMapping168

john_lenfr: Dans notre exemple on a bien demandé l'état en faisant du PORTD sur la pin 13, ce qui nous a bien renvoyé 32 en DEC soit 0b00100000 :grin:

NON je n'ai joué qu'avec le PORT...B soit avec PORTB ou PINB je n'ai jamais touché au PORT..D :grin:

Heu oui, PORTB bien sur :grin:

Bon maintenant que c'est bon pour les PORTX, attaquons les PINX que nous conseille al1fch car au plus "près" de la réalité de l'état de la sortie.

al1fch: En principe , pour une sortie, PORTB et PINB devrait renvoyer la même valeur binaire. (je testerai dès que possible) La nuance c'est que PORTB renvoie l'état de la bascule, l'état 'voulu' en quelque sorte et que PINB renvoie une information prélevée plus près de la broche de sortie, l'état logique 'réel' existant sur la broche elle même. L'article cité simplifie les choses et n'évoque pas le maintien du retour d'info par PINB dans le cas d'une sortie. On ne peut reprocher cela à l'article qui est naturellement simplificateur : une voie pour la sortie, une autre pour l'entrée, pas de mélange des genres pour ne pas embrouiller. Si le schéma te dis quelquechose j'ai mis en bleu la sortie par PORTB vers la broche (jaune) et le retour par PINB (le même retour que pour une entrée) en orange.

PINB - The Port B Input Pins Register - read only (maps to Arduino digital pins 8 to 13 The two high bits (6 & 7) map to the crystal pins and are not usable)

On a vu qu'on a, avec du PINB interrogeant la sortie pin13 de l'arduino (soit PB5 broche 19 de l'atmega): LED ON 60 LED OFF 28

Ce qui nous donne:

ON: 60 en DEC => 0b00111100 OFF:28 en DEC => 0b00011100

Heu, la je fais plus le rapprochement entre le résultat et le pin en question?

:~

john_lenfr:
Heu oui, PORTB bien sur :grin:

Ce qui nous donne:

ON: 60 en DEC => 0b00111100
OFF:28 en DEC => 0b00011100

Heu, la je fais plus le rapprochement entre le résultat et le pin en question?

ici il faut raisonner en bit
le seul bit qui change est bien le bit 5 du port B qui change par le blink , le programme ne fait que ça = faire clignoter la led13

voir bitwise sur
http://arduino.cc/en/Reference/HomePage

Donc cela veut dire que je ne peux pas utiliser PINX pour connaitre l'état d'une sortie car si je veux le faire je suis obligé de changer sont état pour connaitre la différence et interpréter de quelle sortie il s'agit?

Je dois donc rester sur du PORTX, même si c'est moins précis cela me renseignera sur l'état de la sortie et son pin.

?:

Artouste: ``` /*  Blink Turns on an LED on for one second, then off for one second, repeatedly.

This example code is in the public domain. */

// Pin 13 has an LED connected on most Arduino boards. // give it a name: int led = 13; byte pb; // the setup routine runs once when you press reset: void setup() {                  // initialize the digital pin as an output.  pinMode(led, OUTPUT);    Serial.begin(9600);   } // the loop routine runs over and over again forever: void loop() {  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)

 pb=PORTB;  Serial.print("LED ON  ");  Serial.println(pb);  delay(1000); // wait for a second  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW  pb=PORTB;  Serial.print("LED OFF ");  Serial.println(pb);  delay(1000);               // wait for a second }

Et par hasard as-tu essayé un digitalread ?

john_lenfr: Donc cela veut dire que je ne peux pas utiliser PINX pour connaitre l'état d'une sortie car si je veux le faire je suis obligé de changer sont état pour connaitre la différence et interpréter de quelle sortie il s'agit?

Je dois donc rester sur du PORTX, même si c'est moins précis cela me renseignera sur l'état de la sortie et son pin.

?:

là je ne suis plus ton raisonnement : dans les exemples avec la seule led13, que l'info derive de PORTB ou de PINB , l'info est exactement la meme = le bit5 du port B est le reflet de de l'etat de la led

Eh bien en fait c'est la différence entre PORTX et PINX. C'est difficile à expliquer tellement c'est subtil :grin:

Prenons un exemple concret pour illustrer la différence car pour moi il y en a une:

Tout à l'heure nous avons vu que PORTB 0b00100000 (32 en DEC) nous indique directement que c'est le pin 13 qui est en état HIGH. Or, on a vu aussi qu'un PINB nous donne 0b00111100 (60 en DEC) quand c'est à HIGH.

Seulement la différence entre PORT et PIN, c'est que pour PORT je n'ai pas besoin de changer l'état de pin13 pour savoir que c'est le pin13 et qu'il est à HIGH. Alors que pour PIN, je DOIS passer l'état de pin 13 à LOW pour constater que j'ai 28 en DEC => 0b00011100. Je ne peux donc conclure avec PIN qu'en réalisant la "soustraction" PINB HIGH" moins "PINB LOW" pour savoir que c'est le pin 13 qui change d'état.

Seulement, si mon pin 13 pilote un relais qui lui même connecte un appareil, je ne vais pas changer l'état du pin13, c'est à dire déconnecter le relais et donc éteindre l'appareil pour savoir quel est l'état de la sortie...

Justement, le but est de connaitre l'état de la sortie sans "toucher" à quoi que ce soit.

C'est donc pour cela que PORTX est plus adapté.

Est-ce que je suis clair? :grin:

la valeur 32, par rapport à 60 donne une impression de simplicité parce que le code testé par Artouste ne manipule qu'une seule sortie. En cas de manipulation de plusieurs sorties sur le même port on se retrouve , comme pour une lecture de PIN, avec la necessité d'isoler la valeur d'un bit particulier dans un octet. ça se fait par 'masquage' (opération de ET logique) [u]sans modifier quoi que ce soit sur les broches.[/u].

0b00111100 '60' sur les broches 0b00100000 ET '32' (c'est le masque désignant le bit que l'on veut interroger) 0b00100000 = 32

De toutes façon Arduino accepte finalement le digitalRead sur une sortie, ça sera donc plus simple et plus direct ! C'est Arduino qui s'occupera de lire le registre PIN et faire le bon masque ! (-> source dans /hardware/arduino/cores/arduino/wiring_digital.c)

/*
  Blink
 Turns on an LED on for one second, then off for one second, repeatedly.

 This example code is in the public domain.
 */

// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);  
  Serial.begin(9600);  
}
// the loop routine runs over and over again forever:
void loop() {

  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  Serial.print("LED ON  ");
  Serial.println(digitalRead(led));

  delay(1000); // wait for a second

  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  Serial.print("LED OFF ");
  Serial.println(digitalRead(led));

  delay(1000); // wait for a second
}

donne :

LED OFF 0
LED ON  1
LED OFF 0
LED ON  1
LED OFF 0
LED ON  1

héhé, merci al1fch, problème réglé donc.

Je vais dormir moins c** ce soir... :grin: :grin:

al1fch: la valeur 32, par rapport à 60 donne une impression de simplicité parce que le code testé par Artouste ne manipule qu'une seule sortie. En cas de manipulation de plusieurs sorties sur le même port on se retrouve , comme pour une lecture de PIN, avec la necessité d'isoler la valeur d'un bit particulier dans un octet. ça se fait par 'masquage' (opération de ET logique) [u]sans modifier quoi que ce soit sur les broches.[/u].

0b00111100 '60' sur les broches 0b00100000 ET '32' (c'est le masque désignant le bit que l'on veut interroger) 0b00100000 = 32

De toutes façon Arduino accepte finalement le digitalRead sur une sortie, ça sera donc plus simple et plus direct ! C'est Arduino qui s'occupera de lire le registre PIN et faire le bon masque ! (-> source dans /hardware/arduino/cores/arduino/wiring_digital.c)

Quelquefois ce n'est pas desagreable de reflechir même si c'est pour finalement découvrir voir que la roue avait déjà été inventée :grin:

Oui, j'ai appris pas mal de choses avec ce post. Je passe donc en [RESOLU] ! :grin:

Artouste:

al1fch: la valeur 32, par rapport à 60 donne une impression de simplicité parce que le code testé par Artouste ne manipule qu'une seule sortie. En cas de manipulation de plusieurs sorties sur le même port on se retrouve , comme pour une lecture de PIN, avec la necessité d'isoler la valeur d'un bit particulier dans un octet. ça se fait par 'masquage' (opération de ET logique) [u]sans modifier quoi que ce soit sur les broches.[/u].

0b00111100 '60' sur les broches 0b00100000 ET '32' (c'est le masque désignant le bit que l'on veut interroger) 0b00100000 = 32

De toutes façon Arduino accepte finalement le digitalRead sur une sortie, ça sera donc plus simple et plus direct ! C'est Arduino qui s'occupera de lire le registre PIN et faire le bon masque ! (-> source dans /hardware/arduino/cores/arduino/wiring_digital.c)

Quelquefois ce n'est pas desagreable de reflechir même si c'est pour finalement découvrir voir que la roue avait déjà été inventée :grin:

Oué mais des fois aussi c'est pas mal parce que utiliser le langage Arduino est bien plus lent que de jouer directement avec les registres. Et c'est particulierement vrai pour les digitalRead() et digitalWrite(). Perso je passe jamais par les registres parce que je n'ai jamais été confronté à des problème de timing, mais un jour peut-être ... XD

http://jeelabs.org/2010/01/06/pin-io-performance/ http://www.instructables.com/id/Arduino-is-Slow-and-how-to-fix-it/step3/Exspearimintation/

B@tto: Oué mais des fois aussi c'est pas mal parce que utiliser le langage Arduino est bien plus lent que de jouer directement avec les registres. Et c'est particulierement vrai pour les digitalRead() et digitalWrite(). Perso je passe jamais par les registres parce que je n'ai jamais été confronté à des problème de timing, mais un jour peut-être ... XD

Même sans toucher aux registres il est possible d'accélérer les choses de manière significative avec la librairie "digitalWriteFast" ;) http://code.google.com/p/digitalwritefast/