Discussion :

[Artemus24]

Salut à tous.

Le connecteur DB9 sert à la communication analogie d'une liaison serie pour transmettre des données en mode asynchrone.
Comme on peut le voir dans le tableau suivant, il y a neuf fils servant à la communication.

Numéro	Nom	Désignation	Traduction
1	CD	Carrier Detect	Détection de porteuse
2	RXD	Receive Data	Réception de données
3	TXD	Transmit Data	Transmission de données
4	DTR	Data Terminal Ready	Terminal prêt
5	GND	Signal Ground	Masse logique
6	DSR	Data Set Ready	Données prêtes
7	RTS	Request To Send	Prêt à émettre
8	CTS	Clear To Send	Prêt à émettre
9	RI	Ring Indicator	Indicateur de sonnerie
		Shield	Blindage

Ce que j'aimerai connaitre, c'est la relation électronique entre la raspberry Pi 4B et ce connecteur DB9.

Cordialement.
Artemus24.
@+

[Guesset]

Bonjour,

Il y a une bonne explication à cette adresse : https://sti2d.ecolelamache.org/iii_c...t_arduino.html

En résumé, il est possible de se contenter de RX et TX mais ce serait trop simple

Les tensions sont -12V et 12V en RS232 pur jus (il y a des farceurs qui travaillent avec d'autres valeurs y compris du 0-5 Volt). Et le niveau 1 est le -12V donc inversé par rapport au RX/TX des Arduino et autres.

La solution la plus simple est un MAX232 qui fera les adaptations nécessaires.

Salutations

[sevyc64]

Seuls les fils 2, 3, et 5 sont nécessaires pour une connexion série RS232, sans contrôle de flux, ou avec un contrôle de flux logiciel.
Les autres fils sont utilisés lorsque le contrôle de flux est matériel. Ça se rencontre de moins en moins souvent, c'est un héritage des années 70-80, du temps ou il n'y avait pas internet, pas de fibre, pas d'ADSL, et ou les communications se faisaient via des modems RS232.

Les tensions sont -12V et 12V en RS232 pur jus (il y a des farceurs qui travaillent avec d'autres valeurs y compris du 0-5 Volt).

La norme RS232 prévoit une tension entre -3V et -18V pour le "1" logique et entre +3V et +18V pour le 0 logique, avec des valeurs typiques à +12 et -12V.
Pourquoi 12V ? parce que une liaison RS232 est susceptible d'être un peu longue, plusieurs mètres, et que sur la longueur, elle peut capter des parasites. Avec une valeur typique à +/-12V, même avec de gros parasites, ça laisse une marge de +/-6V pour rester dans la norme.


L'état logique de repos étant le "1", certains fabricants considèrent la plage du "1" comme étant de 0 à -18V, ainsi une ligne non alimentée, à 0V donc, est à l'état logique "1" (repos)
Avec cet artifice, une logique TTL (0-5V) voire low-TTL (0-3.3V) branchée directement, peut arriver à fonctionner sur une liaison RS232 moyennant un circuit inverseur.
Mais c'est un contournement de la norme qui "tombe en marche" plus que ne marche réellement.

Avec un gros inconvénient tout de même, si la logique TTL (donc 0-5V) est branchée en direct, avec derrière un appareil, qui lui, respecte la norme soit -12V/+12V voire -18V/+18V, la logique TTL grille instantanément.

C'est la raison pour laquelle, il faut toujours passer par des circuits adaptateurs de la famille des MAX232 le MAX232C est l’ancêtre et le plus connus. Il en existe de nombreux, pas tous sur du 12V d'ailleurs. Mais au moins, normalement ils ont les protections nécessaires pour une vrai liaison RS232.

[Artemus24]

Salut à tous.

Désolé pour mon ignorance, mais je découvre qu'il existe plusieurs liaisons "série" et en plus avec des normes bien différentes.
Si je suis parti du DB9, ce n'est pas que j'en ai un usage mais je connaissais depuis fort longtemps ce type de connecteur.
Ce qui m'interpelle dans ce DB9 est le fait qu'il a neuf fils et un blindage.
Ce connecteur répond à la norme du RS232. Ca, je le savais.

Déjà la différence avec mes Raspberry Pi, j'ai que trois fils, le RxD (Receive Data), le TxD (transmit Data) et le Gnd (Ground).
Comment s'appelle cette norme ? L'UART (Universal Asynchronous Receiver / Transmitter) ? Ou bien TTL ?

Seuls les fils 2, 3, et 5 sont nécessaires pour une connexion série RS232, sans contrôle de flux, ou avec un contrôle de flux logiciel.

J'ai déjà fait l'usage de ces trois fils pour échanger des informations entre Raspberry Pi avec le minicom.

Mais dans le DB9, il y a d'autres fils dont je ne comprends pas trop l'utilité.
Après tout, si ça fonctionne avec trop fils, à quoi peuvent servir les six autres ?

Les autres fils sont utilisés lorsque le contrôle de flux est matériel.

C'est plus destiné à une communication de matériel à matériel indépendamment de l'échange d'informations qui se fait par RcD & TxD.
Je comprends mieux.

Si sur un vieux matériel, j'ai une prise femelle DB9 et que je désire communiquer depuis une de mes Raspberry Pi, est-ce que je dois faire l'usage de ce convertisseur :
--> Convertisseur RS232 - TTL DFR0077

D'après ce que je comprends, le voltage doit être de 12 volts pour une communication via le RS232. Or la Raspberry Pi ne fournit que du 5 Volts.

Ou encore ce hat :
--> Carte d'extension RS232 à deux canaux pour Raspberry Pi

Est-ce compatible ou pas ?

La solution la plus simple est un MAX232 qui fera les adaptations nécessaires.

Comme dans les deux exemples que j'ai donné ci-dessus.

Cordialement.
Artemus24.
@+

[sevyc64]

Désolé pour mon ignorance, mais je découvre qu'il existe plusieurs liaisons "série" et en plus avec des normes bien différentes.

Oui il en existe des quantités, synchrones, asynchrones, avec des niveaux en tension, en courant, voire des systèmes bien plus complexes.

Déjà la différence avec mes Raspberry Pi, j'ai que trois fils, le RxD (Receive Data), le TxD (transmit Data) et le Gnd (Ground).

3 fils, c'est le minimum nécessaire pour une communication série, bidirectionnelle et asynchrone.

Comment s'appelle cette norme ? L'UART (Universal Asynchronous Receiver / Transmitter) ? Ou bien TTL ?

A ma connaissance, il n'y a pas une norme spécifique qui désigne La Communication Série Asynchrone, mais quantités de normes qui définissent les moyens logiciels (protocoles) et matériels (niveaux de tensions/courants, médias de transport, parfois connecteurs, etc ...) de mettre en oeuvre une communication série asynchrone spécifique. RS232 en est une, parmi les plus anciennes (pour ne pas m'engager à dire que c'est la plus ancienne ).

L'UART est, lui, un petit circuit intégré (généralement aujourd'hui directement intégré dans les µC et autres controleurs d'I/O) qui permet de mettre en place une communication série asynchrone. Il converti les signaux de données parallèles en un signal série, et inversement à la reception.

TTL est ici, un abus de langage qui désigne les niveaux de tension des composants logiques, µP,µC, etc... Quand on parle de niveau TTL, on parle de signaux entre 0 et 5V avec un "1" logique à 5V.
TTL est à la base, avec CMOS, une des 2 principales technologies de conceptions des portes logiques et autres circuits intégrés. La technologie TTL ne sait fonctionner qu'avec des signaux en 0-5V, d'où l'abus de langage pour désigner désormais ces niveaux de signaux dans la littérature.
Et par un autre abus de langage, on trouve parfois le terme low-TTL, qui désigne les niveaux des signaux 0-3V ou 0-3.3V des composants dits "faible consommation".

J'ai déjà fait l'usage de ces trois fils pour échanger des informations entre Raspberry Pi avec le minicom.
[....]C'est plus destiné à une communication de matériel à matériel indépendamment de l'échange d'informations qui se fait par RcD & TxD.

Oui, ces autres fils sont les signaux de contrôle du trafic sur la liaison série, du temps ou c'était les modems, et uart qui géraient eux même le débit sur la liaison pour éviter les pertes de données ou la congestion de la ligne.
Si on peut encore rencontrer l'utilisation de ces signaux dans certaines applications, désormais, la puissance de calcul étant nettement supérieure à autrefois, on a tendance à gérer le trafic par des protocoles de contrôle logiciels.

Si sur un vieux matériel, j'ai une prise femelle DB9 et que je désire communiquer depuis une de mes Raspberry Pi, est-ce que je dois faire l'usage de ce convertisseur :
[...]

Oui tu peux utiliser ce genre de module de conversion. A une restriction près, il faut que ton vieux matériel puisse fonctionner avec uniquement les 3 fils de base, ou alors que le module de conversion choisit, prenne en charge les autres fils. Ils sont très nombreux désormais à ne prendre en charge que les fils Rxd et Txd.

Les modules que tu indique utilise les circuits MAX202, pour le premier, SP3232 pour le second. Ceux sont des circuits de la même famille que le MAX232 originel.
Ces circuits n'ont en général besoin que d'une alimentation de 5V (ou entre 3 et 5V pour certains). Ils sont capable de générer eux-même les +12V et -12V nécessaire à la RS232, par un mécanisme dit "à pompe de charges". C'est la raison d'être de la collection de condensateurs qui entourent généralement ces circuits.

[Artemus24]

Salut à tous.

Je ne dois pas me soucier du type de convertisseur ou d'extension pour la Raspberry Pi car ils sont aux normes du RS232.

Mais si le convertisseur (ou la carte d'extension) ne gère pas les autres fils du DB9, est-ce que cela peut poser un problème ?

Cordialement.
Artemus24.
@+

[Delias]

Bonsoir à tous

La norme RS232 défini les grandes lignes, mais pas les détails. D'ailleurs la norme sort initialement sur un DB25 avec encore plus de signaux (et notamment une horloge permettant une transmission synchrone, je n'ai jamais eu de carte ISA suffisamment ancienne pour avoir cette configuration au complet).

Côté électrique ce n'est juste pas la tension qui est définie, mais les impédances des émetteurs (pour éviter de tout cramer si deux sont branchés ensemble) et récepteurs (pour adapter la ligne et éviter les écho, et pour consommer un peu de courant ce qui permet de réduire la sensibilité au bruit). Il y aussi des recommandations sur les pentes de changement d'état pour réduire le bruit générer et limiter la diaphonie. C'est le travail des MAX232 et descendants. Un MAX a traditionnellement deux lignes par sens, et il est possible d'en monter deux pour faire presque toutes les lignes (il en manque alors une en réception).

Pour le nombre de lignes à connecter, cela dépend de l'usage, et surtout de l'époque de l’équipent.
Le RS232 cela date du début de l'informatique. Au début les périphériques n'avaient pas FIFO, et il fallait absolument que l'ordi attendre avant d'envoyer ou de lire un octet (attendre que le traitement du précédent soit terminés). J'ai un appareil qui date des années 80 (et qui était homologué en service officiel jusqu'en 2016) et dont ces lignes servent d'horloge pour le module de communication (Il faut en général plusieurs tentative d'ouverture du port pour que toutes les lignes soient dans le bon état, d'où l'usage rependu à l'époque des analyseur de RS232, 8 Leds qui indiquent l'état des lignes).
Il y a des imprimantes sur port série à chariots (jet d'encre ou aiguilles) de cette époque qui n'ont pas mémoire interne. Les caractères doivent arriver avec le bon timing du déplacement de la tête d'impression. (Merci au grand-papa de m'en n'avoir laisser quelques-unes.) C'est la raison de l'existence de ces lignes.

Le basculement c'est la démocratisation des microcontrôleurs et des mémoires internes qui a permit d'équiper tous ces périphériques de FIFO interne à bas coût permettant de se passer de ces lignes de contrôle.

A noter qu'avec cette génération (années 2000), l'usage général veut que l'on ponte des lignes entre elle au niveau du périphérique (bouclage). Cela permet à l'ordinateur de savoir que c'est branché, mais ces lignes n'existent pas pour le périphérique (en autre le principe des câbles null-modem).

Et pour finir deux lignes sont spécifiques aux modems (dont le dernier cri était le 56k) et qui permettent au modem d'indiquer à l'ordi si la ligne téléphonique est présente ou si un appel entrant est présent. Hors de cette usage ces deux lignes sont inutiles.

La plupart des puces sur USB (la FT232 de FTDI pour la première de la série) gèrent encore la totalité des 8 lignes...

As-tu déjà regardé la totalité des paramètres d'un port com (La commande DOS MODE COMx ...)? Les premiers paramètres définissent les deux lignes TXD et RXD, mais le reste c'est l'usage qui est fait des ces lignes de commande.

J'ai remarqué que sur les microcontrôleurs les lignes de contrôle ne sont pas implémentée de manière hardware, mais peuvent l'être de manière software si on en a vraiment besoin, cas très minoritaires. Pour le Pi je ne sais pas.

Delias

[sevyc64]

J'ai remarqué que sur les microcontrôleurs les lignes de contrôle ne sont pas implémentée de manière hardware, mais peuvent l'être de manière software si on en a vraiment besoin, cas très minoritaires.

Les lignes de contrôle ne sont plus implémentées car d'usage, désormais, plus qu’anecdotique. Au mieux, si le périphérique en a besoin, on boucle, comme tu as dis, certaines lignes entre-elles dans les connecteurs.

Au pire, si les lignes de contrôle sont absolument necessaires, on les refait avec quelques port I/O disponibles. Mais il faut alors se gérer tout le protocole qui en découle dans le soft.

De nos jours, la puissance de calcul est telle, même sur du RPi, Arduino et consort, que l'on préfère travailler en direct live, sans contrôle hardware, mais avec un protocole plus poussé, niveau soft, avec CRC, acquitements, demande de retransmissions, etc ...

Pour info, un protocole type TCP/IP passe sur du RS232. Bon après, faut pas vouloir faire du streaming 8K avec

Mais si le convertisseur (ou la carte d'extension) ne gère pas les autres fils du DB9, est-ce que cela peut poser un problème ?

Çà ne pose pas de problème, si ton périphérique n'en a pas besoin pour fonctionner.

[Artemus24]

Salut à tous.

Merci pour les explications !

Cordialement.
Artemus24.
@+

[Delias]

Bonsoir à tous

Grace au lien que tu as donné dans ton nouveau sujet, j'ai suivi jusqu'à une doc du Pi: https://datasheets.raspberrypi.com/b...eripherals.pdf où il est indiqué que le Pi 4 gère de manière matériel les deux signaux CTS et RTS sur ses UART PL011 (5 des 6 ports séries du Pi).

Et toute la discussion d'avant n'a pas parlé des usages détournés de ces lignes de contrôle. Les plus connues étant probablement les programmateurs ISP. Arduino en fait également usage puisque c'est le DTR qui sert de commande de Reset permettant de lancer le Bootloader pour la programmation de la puce.

Delias