Discussion :

[samr037]

Bonjour à tous !!

Je suis actuellement sur un projet d'études qui nécessite l'utilisation de ports RS485 pour communiquer avec différents capteurs assez distants (d'où le RS485), pour cela j'ai une carte électronique disposant de 4 ports RS485 reliés aux port I2C du Raspberry via des puces NXP SC16IS740 (Datasheet).

J'arrive à communiquer en RS485 vers mes capteurs grace à un script en python, la transmission se passe bien mais la reception est un peu plus complexe car les SC16 ont un buffer FIFO de 64 Octets seulement et cela pose problème pour la communication avec un modem GPRS

J'ai appris récemment qu'il existe un driver sous Linux pour piloter les SC16 et avoir un nouveau port série (ttySCxx) dans /dev/, ce driver n'étant pas compilé dans la version de base de Raspbian, j'ai compilé moi même le kernel en l'incluant. Tout s'est très bien passé, le module se lance sans erreur mais aucun nouveau port série n’apparaît dans /dev/...

J'ai tenté plusieurs manipulations, lancement des modules i2c-dev, i2c-bcm2708, regmap-i2c, etc. mais rien n'a l'air de fonctionner, je suis assez désespéré...

Le driver installé est le suivant (Lien Github)

Pouvez-vous m'aider à faire fonctionner ce driver ?
N'hésitez pas à demander pour avoir plus d'informations..

Merci de votre aide.

[Vincent PETIT]

Bonsoir,

Bonjour à tous !!

Je suis actuellement sur un projet d'études qui nécessite l'utilisation de ports RS485 pour communiquer avec différents capteurs assez distants (d'où le RS485), pour cela j'ai une carte électronique disposant de 4 ports RS485 reliés aux port I2C du Raspberry via des puces NXP SC16IS740 (Datasheet).

4 UART ???? Le nombre de capteur doit être impressionnant dans la mesure où sur 1 seul UART avec un LTC485 (par exemple) tu peux aller jusque 32 esclaves.

J'arrive à communiquer en RS485 vers mes capteurs grace à un script en python, la transmission se passe bien mais la reception est un peu plus complexe car les SC16 ont un buffer FIFO de 64 Octets seulement et cela pose problème pour la communication avec un modem GPRS

Tu communiques avec quel protocole ?
En regardant rapidement ta doc constructeur, n'y a t-il pas une interruption IRQ/ qui peut t'indiquer que la pile est pleine ? Ou la présence du stop bit ?
Il serait étonnant que tu n'ais aucune indication la dessus.

Si tu trouves (car j'ai eu beau travailler 12 ans dans l'industrie électronique, je suis un peu rouillé, pour le moment, pour éplucher ta doc dans son intégralité) alors la pile de 64 octets ne sera plus un problème puisque tu viendras la lire puis la vider au fur est à mesure, pour la stocker dans une pile de la taille que tu souhaites dans ton Raspberry.

J'ai appris récemment qu'il existe un driver sous Linux pour piloter les SC16 et avoir un nouveau port série (ttySCxx) dans /dev/, ce driver n'étant pas compilé dans la version de base de Raspbian, j'ai compilé moi même le kernel en l'incluant. Tout s'est très bien passé, le module se lance sans erreur mais aucun nouveau port série n’apparaît dans /dev/...

J'ai tenté plusieurs manipulations, lancement des modules i2c-dev, i2c-bcm2708, regmap-i2c, etc. mais rien n'a l'air de fonctionner, je suis assez désespéré...

Le driver installé est le suivant (Lien Github)

Pouvez-vous m'aider à faire fonctionner ce driver ?
N'hésitez pas à demander pour avoir plus d'informations..

Merci de votre aide.

A mon idée, je ne vois pas pourquoi cela résoudrait ton problème de FIFO trop petite. Il faut juste aller la lire avant qu'elle ne déborde et ça ton SC16ISxxx doit pouvoir te le dire en jouant un peu avec ses registres (sa config si tu préfères).

[samr037]

Bonjour Vincent,

D'abord merci d'avoir répondu

Le modem devra communiquer en PPP, c'est pour cela qu'une interface dans /dev/ aurait été un grand luxe, et quand au choix technique de mettre 4 bus RS485 sur la même carte, ce n'est pas le mien, sachant que c'est un projet d'étude, le matériel est déjà fourni. Sinon, je pense que j'aurais choisi l'utilisation du SPI, plus rapide, ou même de l'USB pour convertir en RS485, moins cher, plus rapide et très simple d'installation..

Mon choix d'utiliser un driver est simplement pour pouvoir communiquer le plus vite possible, je pense qu'être au plus près du kernel est préférable.

J'ai fais pas mal de chemin depuis la dernière fois, et j'ai découvert l'apparition recente du Device Tree sur les noyaux linux, et cela a facilité beaucoup les choses de mon côté, j'ai reussi à lancer le fameux driver et il fonctionne , du moins, du côté émission, j'ai même le ttySC0 dans /dev/ Cependant, comme tu l'as si bien dis, un IRQ est disponible sur les SC16IS, et dans mon cas, il est câblé sur un GPIO du raspberry.

Pour schématiser rapidement, mon montage ressemble beaucoup à celui ci (page 32)

Voici la configuration du Device Tree sur mon Raspberry (bcm2708-rpi-b.dts) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
&i2c1 {
	pinctrl-names = "default";
	pinctrl-0 = <&i2c1_pins>;
	clock-frequency = <100000>;
	sc16is7401: sc16is740@48 {
		compatible = "nxp,sc16is740";
		reg = <0x48>;
		clocks = <&clk20m>;
		interrupt-parent = <&gpio>;
		interrupts = <&gpio 22 7>;     // dans mon cas le premier SC16IS est cablé sur le GPIO 22, mais cela ne fonctionne pas, il n'intercepte pas l'IRQ
	};
};

Une documentation précise le mode d'utilisation du device tree pour les SC16IS mais elle est assez imprécise et surtout très générale...

Je pense être sur la bonne voie, car cela fonctionne au moins en emission (pas besoin d'IRQ pour ça), mais il y a semble t-il encore du chemin..

Mes questions maintenant sont les suivantes :

Comment puis-je intercepter un IRQ sur un Raspberry en utilisant les GPIO et Device Tree ?

Est-il possible d'instancier plusieurs fois le même driver sans conflit ? (J'ai dupliqué la déclaration dans Device Tree, changé les index et adresses I2c, mais il a essayé d'instancier deux périphériques sur le ttySC0 )

Merci beaucoup à ceux qui auront le courage de me lire jusqu'au bout
Très bonne journée à tous !

[Vincent PETIT]

Bonsoir,
Dans la page 8 de ta doc, il y a une information importante sur l'interruption IRQ

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
IRQ 7 14 11 Output 
Interrupt (open-drain, active LOW). Interrupt is enabled when
interrupt sources are enabled in the Interrupt Enable Register
(IER). Interrupt conditions include: change of state of the input
pins, receiver errors, available receiver buffer data, available
transmit buffer space, or when a modem status flag is detected. An
external resistor (1 k for 3.3 V, 1.5 k for 2.5 V) must be
connected between this pin and VDD.

available receiver buffer data Données disponibles dans le buffer de réception (j'entends par là, le registre RHR, qui une fois remplie, se déverse dans la FIFO).
Une résistance doit être connectée au VDD, la valeur dépendra de la tension d'alimentation de ton shiel. Et cette broche passera à l'état 0 quand les données seront disponibles dans la pile.

Ensuite à la page 16, il y a écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
7.5.1 Interrupt mode operation
In Interrupt mode (if any bit of IER[3:0] is
1) the host is informed of the status of the
receiver and transmitter by an interrupt signal, IRQ
. Therefore, it is not necessary to
continuously poll the Line Status Register (LSR) to see if any interrupt needs to be
serviced.
Figure 13
shows Interrupt mode operation.

Si tu mets la valeur 15 dans le registre IER du composant, tu devrais être avertie de toute opération de lecture / écriture dans les registres RHT/THR de ce dernier.
A partir de ça, moi je ferai des tests avec un simple oscilloscope sur la broche IRQ. Je pense qu'elle passera à l'état bas à chaque octet reçu ou envoyé.
Toujours selon moi, si tu envois 2 octets (donc 16 bits) la broche IRQ passera 2 fois à l'état bas, la première fois, dès qu'elle aura vu passer le premier octet et une autre fois dès que le second octet est passé.

Si j'ai raison alors tu pourra passer à la suite, c'est à dire mettre dans le registre IER non pas la valeur 15 mais plutôt la valeur 1 si tu veux être avertie uniquement dès qu'un octet est arrivé dans le composant. Connaissant la taille de la FIFO, tu ne devrais donc pas être obligé d'aller lire le composant souvent, il devrait être suffisant de compter le nombre de fois où IRQ est passé à l'état bas.

Si pour une raison que j'ignore tu voudrais te servir de IRQ pour plusieurs choses (voir page 29) alors il te faudra lire le registre IIR (de la page 30) pour savoir qu'est ce qui a déclenché l'interruption IRQ.

Côté Raspberry, je n'ai pas encore déballé le mien et je ne sais pas si ton OS (Raspbian) peut où non avoir une broche d'interruption ? Car il y a un soucis de taille :
Si je ne me suis pas trompé dans mon analyse du composant. La broche IRQ passe à l'état bas, par exemple, une fois qu'un octet est arrivé mais la broche IRQ repassera à l'état haut très vite après. Si le Raspberry, n'a pas eu le temps de lire la broche IRQ ça ne fonctionnera pas.

Exemple, tu décides de dire à ton Raspberry d'aller lire l'état de la broche IRQ tous les 100ms alors il se peut que ta broche IRQ passe à l'état bas entre 2 lectures du Raspberry et ce dernier ne l'aura pas vu et ne sera donc pas avertie que un ou des octets sont entrain d'arriver dans le composant NXP !!!!
Il faut d'abord savoir si le Raspberry a une broche d'interruption.

J'ai beaucoup fait de hardware et une chose est sur... la broche IRQ du NXP doit être relié sur une broche interruptible de son hôte (donc ton Raspberry)

C'est mon analyse du composant.
Par contre tes tests m'intéressent, ne serai ce que pour savoir si je me suis trompé ou non.

D'avance merci si tu à la possibilité de me tenir au courant.
Cordialement,

[samr037]

Bonjour Vincent !

J'avais promis de te tenir au courant, alors voilà.

J'ai réussi à régler tous mes problèmes avec le driver et Device tree, j'ai pu instancier les 4 drivers et j'ai pu enfin me focaliser sur la partie electronique.

J'ai pas mal modifié le driver et ses registres pour qu'il prenne en charge le RS485 et tout fonctionne... presque... La réception fonctionne à la perfection (l'IRQ est parfaitement gérée), mais la transmission pose maintenant quelques soucis, je reçoit chaque octet transmis.

Pourtant les registres sont bien paramétrés, j'ai mis un log sur chaque IRQ reçue et à chaque transmission, je reçoit [RS485 IRQ] - IIR : 12 (0x0C) - IER : 1 - EFCR : 48 (0x30). Tous les registres sont bons donc mais l'IRQ est déclanchée par un seul octet étant resté en FIFO (Time Out).

Mon système se présente de la manière suivante : la broche RTS du SC16IS740 est cablée sur la broche DE de mon convertisseur UART => RS485 (un SN65HVD12DD : Documentation), donc quand le RTS est à 1, je transmet et quand mon RTS est à 0, je reçoit.

Je ne peux pas déterminer si le problème est électronique pur (signal RTS qui redescends trop tôt) ou si c'est un soucis de gestion de la FIFO par le composant. Je n'ai qu'un oscilloscope une voie .

J'ai essayé plusieurs choses pour gérer le soucis :
- Ignorer le premier octet reçu après chaque TX (fonctionne à très basse vitesse, même si codé dans le driver..)
- Vidage de la FIFO après chaque TX (encore plus lent, et très lourd pour l'I2C)

Je ne vois aucun registre permettant de régler ce soucis...

Si tu as une idée...

Bonne soirée

[Vincent PETIT]

Bonsoir samr037,
Tout d'abord merci d'avoir répondu.

Afin de faire le tour du problème et essayer de le résoudre, je vais devoir te poser plusieurs questions.

Postulat a vérifier en premier :
- Les niveaux de tensions entre le Raspberry et le shield NXP SC16IS740 et le driver RS485 sont identiques. Tout est en +5V ou +3.3V afin que cela cause bien.
- Les masses ou 0V de toutes les cartes électroniques (Shield) sont bien communes, c'est à dire reliées entre elles. Sinon est état bas sur le Raspberry par exemple, n'est pas forcément un état bas sur le Shield !!!
- Les broches DE et RE/ du driver RS485 sont reliées ensemble pour éviter que RE/ soit une antenne. Quand RTS est à 1 alors DE est à 1 = émission mais comme RE/ est à 1 aussi (car reliée à DE) alors la réception est bloqué en haute impédance.


Éliminons dans la foulée un éventuel problème de désadaptation d'impédance (qui se caractérise par un écho sur le câble)
- As tu une résistance de 100 ou 120 Ohms entre les broches A et B du drivers RS485 de tête ?

J'entends pas là le driver RS485 qui juste après le composant NXP.

- As tu une résistance de 100 ou 120 Ohms entre les broches A et B du drivers RS485 de fin de ligne ?

J'entends pas là le driver RS485 qui est tout au bout de la ligne (du câble).

Ces 2 résistances de début et de fin de ligne sont extrêmement importantes car elles assurent l'adaptation d'impédance de la ligne de communication et cas de desadaptation il y a un écho sur le câble. C'est une manipulation qui se voit bien avec un oscilloscope.

A bientôt,
Vincent

[samr037]

Bonsoir Vincent,

Ayant conscience des phénomènes de mauvaise adaptation d'impédance, j'ai déjà vérifié tous ces points :
- Les niveaux de tension sont bien identiques
- Les masses sont communes
- Le DE et RE/ ne sont pas reliés, j'ai eu un doute là dessus mais ceci peut-il vraiment faire le retour d'un octet complet ?? ça paraît assez énorme...

- Le driver RS485 sur ma carte est bien équipé de la resistance de 120 Ohm
- Le périphérique en fin de ligne en est également équipé, c'est un convertisseur USB => RS485 GMM, j'ai confirmé l'information en analysant le PCB


Merci de ton aide

[samr037]

OK... C'est à cause des DE et RE/ non reliés... Une rapide analyse de la datasheet du convertisseur RS485 permet de mettre en évidence la bêtise...

Je vais corriger ça demain et tester, je te tiendrais au courant de l'avancement de la situation.

Merci de ton aide

[Vincent PETIT]

Salut Sam,
Ce n'est peut être pas la cause du problème mais mon expérience me permet de dire aujourd'hui qu'une entrée en l'air est potentiellement source d'ennuie.

C'est un doute qui peut être levé en tout cas.

Je testais la C.E.M. moi même sur les appareils que je développais à l'époque (rayonnement électromagnétique, injection capacitive et inductive, décharge électrostatique, ...) pour avoir la certification "CE" lorsque je travaillais dans un laboratoire de R&D en électronique. Et une entrée qui reste en l'air avec ce genre de test, ça ne pardonne pas.

Merci de ton retour,
Bien à toi.

[samr037]

Ça fonctionne !

C'était bien le DE et le RE/ non reliés, c'était même pire, le RE/ était relié à la masse, donc la réception en permanence active, même pendant la transmission !

Tout fonctionne presque à la perfection maintenant, j'ai juste un soucis : minicom peux communiquer mais pas les autres programmes . je vais mettre des entrées log dans le driver pour voir si au moins ils essayent de communiquer...


Merci beaucoup pour ton aide !

EDIT :
C'était à cause du contrôle de flux Hardware activé par défaut sur certains programmes, un petit "termios->c_cflag &= ~CRTSCTS;" et c'est réglé, tout fonctionne maintenant à la perfection !!!!

Merci beaucoup de ton aide ! Bonne continuation !

[Vincent PETIT]

Pas de quoi, je suis content que tu sois parvenu à faire ce que tu voulais.

Je me souhaite aussi bonne continuation car je suis apparemment encore très au point niveau hardware mais niveau soft.... :S
J'ai fait beaucoup de C sur microcontroleur et en ce moment je suis entrain d'apprendre JAVA, je pense être sur la bonne voie pour casser la barrière entre électronicien et informaticien.

Bien à toi.
Vincent

pense a mettre Résolu dans le titre du sujet.