Conversion de mot en binaire et inversement

Bonjour à tous,

Cela fait un moment que je cherche comment je peux effectuer la conversion de mot en binaire sur Arduino sans résultat flagrant. En effet, j'ai pour projet de transmettre des messages par la fibre optique.

Dans un premier temps je voudrais simplement traduire mon mot en impulsion lumineuse mais tout ce que j'arrive à faire c'est de laisser ma LED allumé.

Pour le moment j'ai réussi à récupéré dans le moniteur série la valeur binaire d'une lettre mais pas dans le code en lui-même.

Es ce que quelqu'un aurait une idée pour m'aider?

Merci d'avance,

Nathanaëlle

Le binaire est une représentation textuelle, ce n'est pas une organisation mémoire.

'A' = 65 = 0x41 = '\x41' = 0b1000001

Ensuite si tu veux connaître l'état de chaque bit d'un octet il faut procéder par décalage :

void setup() {
  Serial.begin(115200);
  char b = 'A';
  Serial.println(b == 65 ? "YES" : "NO");
  Serial.println(b == 0x41 ? "YES" : "NO");
  Serial.println(b == '\x41' ? "YES" : "NO");
  Serial.println(b == 0b01000001 ? "YES" : "NO");
  for (int i = 0 ; i < 8 ; i++) {
    Serial.println(b & 0x01);
    b >>= 1;
  }
}

void loop() {
  // put your main code here, to run repeatedly:

}

Je comprend que c'est n'est qu'une représentation textuel, mais je suis désolé, je ne suis pas sûr d'avoir très bien compris la suite.
Pensez-vous pouvoir essayé de m'expliquer de nouveau ?

Merci d'avance,
Nathanaëlle

Le binaire n'existe que dans l'esprit humain.

Si on affiche la lettre 'A' sur la console :

  Serial.println(b);
  Serial.println(b, DEC);
  Serial.println(b, HEX);
  Serial.println(b, BIN);

Cela produira la sortie suivante :

A
65
41
1000001

C'est toujours le même caractère en mémoire, mais affiché différemment.

As-tu compris l'histoire de décalage ?

Oui ça j'avais compris.
Les lignes de codes que vous venez d'afficher sont celles que j'ai su faire. Mais je ne vois justement pas comment je peux récupérer la valeur décimal.

Le décalage pas vraiment, c'était surtout ça dont j'aurais aimé une explication. Je suis désolé, je ne me suis pas très bien exprimer.

Merci en tout cas, de prendre le temps de m'expliquer, cela m'aide beaucoup.

Nathanaëlle

Mais je ne vois justement pas comment je peux récupérer la valeur décimal.

Il faudrait expliquer quel est le but de la manœuvre.

Ne t'inquiète pas, peu de gens comprennent immédiatement. Il n'y a rien d'anormal.

Reprenons :

Il n'y a aucune conversion à faire. Un caractère en mémoire est binaire avant tout. Un 'A' reste une suite de 0 et de 1 : 1000001 et c'est tout.

Comme je l'ai déjà dit un caractère n'a pas de valeur décimale. C'est une suite de 8 bits qui ont chacun une valeur 1 ou 0.

On peut l'afficher de la manière qui nous arrange, y compris décimale, mais cela n'est qu'une représentation pour l’œil humain, ou plutôt le cerveau, plus habitué au décimal.

Le décalage pas vraiment, c'était surtout ça dont j'aurais aimé une explication. Je suis désolé, je ne me suis pas très bien exprimer.

Considérons l'opération suivante :

char b = 'A'; // 10000001
Serial.println(b & 0x01);
b >>= 1;

b vaut donc 'A', donc 41 en hexadécimal, et 1000001 en binaire, en mémoire au départ.
Le bit de poids fort est à gauche, le bit de poids faible à droite.

b & 0x01 représente un ET binaire.

0x01 vaut 00000001 en binaire. Si l'on fait l'opération 1000001 ET 00000001 on obtient 1.
1 est le bit de poids faible de 10000001.

Ensuite on décale vers la droite :

b >>= 1;

Tous les bits sont décalés vers la droite, le bit de poids faible est perdu.

b devient donc égal à 01000000.

Le bit de poids fort est décalé également vers la droite.

Si l'on refait l'opération b & 00000001 on obtient 0.
0 est le bit de poids faible de 01000000.

Si l'on répète l'opération 8 fois de suite, b vaut forcément 00000000 à la fin.

On peut décaler à droite, à gauche, de 1 bits ou plusieurs :

b <<= 1;
b >>= 1;
b <<= 2;
b >>= 3;

b <<= 1; étant une contraction de b = b << 1;

Tu peux essayer les opérations binaires avec une calculette de programmation ou même des pions noirs et blancs.

Mettons que tu as un bout de fibre optique avec un émetteur de lumière d'un côté et un récepteur photosensible à l'autre bout. Pour transmettre, il faut exciter la led avec un signal et lire le signal produit de l'autre côté par le récepteur.
Cela revient à mettre en place un protocole de transmission série (c'est en série parce que t'un n'as qu'une liaison donc les bits sont transmis un par un à la suite). Tu peux bien sûr partir de 0 et inventer ton propre protocole mais si tu ne veux pas réinventer le fil à couper le beurre, tu peux simplement faire ça en TTL avec la fonction Serial. Tu n'as pas à te préoccuper de convertir les caractères en binaire, la fonction le fait pour toi (comme expliqué ci-dessus, elle ne connaît que ça donc quand tu stockes un caractère en mémoire, il l'est déjà sous forme d'un octet : tout ce que tu tapes dans l'IDE est compilé en langage machine). En bref, tout ce que tu as à faire est de brancher la led sur le pin Tx et le récepteur sur le Rx d'un autre arduino. Bien entendu, pour que la liaison soit à deux sens, il faudrait mettre de chaque côté une led et un récepteur et connecter les led aux Tx et les récepteurs aux Rx. Est-ce que c'est plus clair pour toi?

Sans passer par le protocole de la liaison série, parce qu'un protocole c'est une charge supplémentaire qui n'est pas forcément utile, tu peux tout simplement utiliser la fonction shiftOut() qui est prévue pour charger en série un registre à décalage.
Si tu fait des recherche sur 74HC595 tu trouvera plus d'exemples que tu n'aura le temps de les lire.

Et si tu fait cette recherche en utilisant la loupe (en haut et à gauche de cette page) tu aura en priorité les exemples en français de ce forum.

En effet, j'ai pour projet de transmettre des messages par la fibre optique.

Peut-être que si tu en disais plus tu recevrai une aide mieux adaptée.
En particulier quel débit ?
Quel type de composants optiques ?
Quel type de fibre ?

Émission permanente ou mode rafale (burst).
Si c'est du mode rafale un protocole de communication comme la liaison série peut se révéler indispensable.

En effet, j'ai pour projet de transmettre des messages par la fibre optique.

Je n'avais pas vu cette phrase :confused:

Effectivement comme dit 68tjs, shiftOut est une solution pour transférer des bits sur un fil, cela fait exactement le même travail que ce que j'ai décrit plus haut, sauf que tu n'as pas besoin de faire ce travail de décalages à la main.

Mais cela ne change rien au problème qui te préoccupe : binaire, décimal, etc.

Si tu transmets 'A' ou 'Z' tu récupères 'A' 'Z' à l'autre bout.
Attention toutefois au bitOrder.

hbachetti:
Le binaire n'existe que dans l'esprit humain.

+1

J'insiste sur le point : mode continu ou mode rafale ?
En matière de transmission la différence est importante.

En mode continu on distingue deux phases :

  • la phase de synchro qui peut être longue mais qui ne se produit qu'à la mise en service.
  • la phase fonctionnement permanent pour éviter la désynchronisation.

C'est le principe des communications téléphoniques, entre les nœuds du réseau les échanges sont permanents.
La synchronisation d'un nœud sur le réseau peut prendre plusieurs dizaines de secondes.
Les échanges se font par trame. Dans une trame il y a les informations de gestion et la charge utile (en anglais Payload). Quand il n'y a rien à transmettre une séquence spéciale dite "bits de bourrage" est placée dans la charge utile pour conserver la synchronisation.

En mode rafale (burst en anglais) la synchronisation n'est pas permanente et le récepteur doit se mettre rapidement en état de comprendre ce que l'émetteur lui envoie.
Dans le protocole de transmission de la RS232 c'est le rôle des bits "superflus" : start, stop, etc.
De plus la RS232 part du principe que la fréquence est parfaitement stable pour simplifier la synchronisation. C'est pourquoi une carte arduino à un résonateur relativement peu précis pour le micro principal et un vrai quartz pour le CI qui est sur la liaison série à la norme du protocole RS232.

ShiftOut ou RS232 : tout dépend du reste du projet.

Bonjour,
Tout d'abord merci beaucoup à vous tous de l'aide que vous m'apportez.

Merci, hbachetti de tes explications qui sont très claires. Je comprend mieux et je vois maintenant comment je vais pouvoir l'utiliser dans mon projet. Pensez-vous que je puisse de la même manière faire l'opération inverse ? C'est-à-dire que si je stocke mes valeurs récupérées(0 et 1) je vais pouvoir afficher sur un écran le mot initial ?

Barsa972:
Mettons que tu as un bout de fibre optique avec un émetteur de lumière d'un côté et un récepteur photosensible à l'autre bout. Pour transmettre, il faut exciter la led avec un signal et lire le signal produit de l'autre côté par le récepteur.
Cela revient à mettre en place un protocole de transmission série.

C'est un peu le but final de mon opération mais je ne savais pas qu'il existait déjà des protocoles pour effectuer ceci. Je vais me renseigner, quitte à faire plusieurs version cela est toujours intéressant ^^ En tout cas merci beaucoup de cette piste Barsa972.

68tjs:
tu peux tout simplement utiliser la fonction shiftOut()

Je ne connaissait pas non plus cette fonction, je vais me renseigner. Merci beaucoup,68tjs.

68tjs:
Peut-être que si tu en disais plus tu recevrai une aide mieux adaptée.
En particulier quel débit ?
Quel type de composants optiques ?
Quel type de fibre ?

Émission permanente ou mode rafale (burst).
Si c'est du mode rafale un protocole de communication comme la liaison série peut se révéler indispensable.

Je suis désolé, je ne savais pas exactement comment préciser l'ensemble. En gros je cherche juste à transmettre un message via la fibre optique pour essayé d'analyser un peu le fonctionnement dans le cadre de mon projet TIPE.
Je ne me suis pas spécialement penché sur un débit fixé pour le moment, puisque je bloquais sur la conversion. Mais je ne demande pas un débit ultra-élevé non plus, c'est plus pour faire un test de comparaison avec une liaison série par câble.
Au niveau des composants j'utilise une LED et une photorésistance à seuil réglable(Je ne sais pas si vous les références peuvent aider...)
La fibre optique est une fibre monomode, très simple.
Quand à l'émission le mode permanent me semblait plus simple, mais après je peux me tromper, je ne m'y connais pas beaucoup je dois avouer...

En tout cas merci encore, vous m'avez offert pas mal de piste pour essayé d'avancer ^^ Je regarderais en détail ce que je peux faire dans l'après-midi ou ce week-end. Mais merci encore !!!!

C'est-à-dire que si je stocke mes valeurs récupérées(0 et 1) je vais pouvoir afficher sur un écran le mot initial ?

Toute la difficulté va être là.
La fonction shiftout émet un octet sur deux fils (data et clock), le fil clock donne le rythme au récepteur.

Comme je suppose qu'il n'y a qu'une seule fibre, seule la data sera émise et reçue.

A moins de vouloir faire un exercice de style, il va être compliqué de recevoir, à moins de connaître précisément le débit de shiftout en bits / seconde, de démarrer un timer pour donner le rythme, avec une tolérance, etc.

Le problème est qu'avec 8 bits seulement il va être difficile de transmettre 8 bits effectifs. Si le premier bit à transmettre est un 1 c'est lui qui donne le top départ, mais s'il est à 0, cela ne marche pas. Il faudrait un bit de start, un bit de stop.

Comme disait Barsa972 tu pourrais te rabattre sur Serial.write(), qui saura émettre le start, les datas, et le stop.
A L'autre bout, un appel à Serial.available() te dira si un octet est reçu, si oui tu appelles Serial.read().

Avec Serial tu va pouvoir disposer de toute la panoplie de fonctions associées.

J'ai la possibilité d'utiliser deux fibres, mais l'idée de base n'en concernait qu'une, en effet.
Donc si je comprend bien, reformer le message risque d'être compliqué et si je veux le récupérer je ne pourrais le faire que sur le moniteur série et non pas, par exemple sur un écran LCD. Es ce que c'est bien ça ?

Non, quel que soit l'affichage cela ne change rien.

Le problème est de détecter le premier bit.

Au repos l'entrée sera à 0 ->si le premier bit est 0 on ne le verra pas.

Essaie avec Serial.
Pour cela il faudrait savoir de quelle plateforme il s'agit, UNO, MEGA, etc.

La fibre optique est une fibre monomode, très simple.

Une fibre monomode une fibre toute simple ?
Je ne le pense vraiment pas et du reste je ne pense pas que tu ais une fibre monomode.

Le terme mono mode signifie que le cœur de la fibre est tout petit (9 à 10 µm) afin que seuls les rayons qui frappent bien perpendiculairement l'extrémité de la fibre puissent y pénétrer. Comme ils frappent la surface de la section de fibre perpendiculairement, d'après la loi de Descartes, il ne sont pas déviés et leur trajet est direct dans la fibre.
Les fibres monomode sont utilisées pour des distances de 50 km ......aux traversées transocéanique de 6000 ou 7000 km.

La fibre dont tu dispose est très certainement une fibre multimode, (cœur à partir de 50µm) terme qui signifie qu'en plus des rayons précédents d'autres rayons provenant de plusieurs directions vont se propager dans la fibre en rebondissant sur les parois.
Le trajet de ces rayons étant plus long ils n'arrivent pas en même temps à l'extrémité de la fibre.
Conséquence un signal émis bien rectangulaire se transformera en une horrible patatoïde à l'arrivée.
Deux paramètres interviennent pour limiter l'usage de cette fibre : la longueur de la fibre et la période du signal élémentaire à transmettre.

Les raccordement fibre internet (200 MHz max) se font en fibre multimode sur quelques km.

L'utilisation de fibre, même bas de gamme, plastique cœur diamètre 250 µm ou plus, va demander l'utilisation de connectique délicate : raccorder deux fibres c'est autre chose que de raccorder deux fils de cuivre => pour info j'ai commencé à manipuler mes premières fibres vers 1976/78, je connais un peu.

Je reconnais avoir répondu trop vite quand j'ai suggéré l'usage de shiftOut.
J'ai répondu sur un point technique précis sans avoir pris le temps de bien analyser ton projet.
AMHA c'est une très mauvaise idée de transmettre un signal et son horloge sur deux fibres séparées, comme sur deux fils de cuivre séparés dès qu'il y a de la distance.

Cela ne se fait jamais et c'est qu'il y a des raisons autres que le coût.
Dans les télécommunications le signal Data est codé afin que, dans le récepteur, on puisse récupérer le signal horloge à partir du signal Data.
Et pas seulement pour les grandes distance, on procède ainsi entre deux racks à l'intérieur d'une simple armoire sur des distances de moins d'un mètre..

Des protocoles ont été mis au point comme la liaison série.
La liaison série fonctionne à condition que la fréquence de l'horloge soit bien connue et très stable.
Ce sont ces deux conditions qui permettent de ne pas avoir besoin de fournir une horloge.
En fait quand Barsa972 et hbachetti te conseillent d'utiliser SerialWrite ils te donnent le point d'entrée pour utiliser la liaison série.

Peut-être que j'ai encore mal relu mais je n'ai pas trouvé à quelle distance tu veux transmettre ?

Le gros avantage de Serial est que le contrôleur interrompt les tâches dès qu'il y a réception sur Rx et stocke les données dans une mémoire tampon à laquelle on peut accéder en décalé. Donc tu ne perds pas des données pendant que ton programme est occupé à gérer l'affichage sur ton LCD. Après si c'est purement pédagogique, il peut être intéressant de reconstruire tout cela à partir des commandes les plus basiques.

Actuellement je travail avec une UNO.

Je vois bien le problème... Je n'y avait pas pensée, je vais prendre le temps de réfléchir à ce sujet. Mais à première vue comme ça, je ne vais pas avoir d'autre choix que de passer par un bit de démarrage est un bit de stop.

En supposant que j'arrive à trouvé une solution pour ce problème, le conversion inverse devrait marché de la même manière non, en décalage?

Merci beaucoup en tout cas ^^

Je pense qu'il faut faire une RAZ.

Il faut arrêter, pour le moment, de discuter réalisation matérielle et logicielle.
Il faut comprendre exactement ce que tu veux faire.

Les informations arrivent les unes après les autres : ce n'est possible de travailler comme cela.
Explique mieux ton projet.
Détaille ton matériel.

Mais à première vue comme ça, je ne vais pas avoir d'autre choix que de passer par un bit de démarrage est un bit de stop.

La ligne série fait ce travail pour toi :

Une UNO ne dispose que d'une ligne série, donc il faudra passer pas un objet SoftwareSerial.

Le débit sera faible, mais si c'est pour un exercice, cela ne devrait pas être gênant.

Sinon :

68tjs:
comprendre exactement ce que tu veux faire

serait préférable.

Quel type de projet : scolaire ou non, etc.