Bus de communication

[invite826167ad]

Bonjour,


Je suis en apprentissage dans une petite entreprise de Distribution Automatique.

Actuellement, je fais des recherches sur les différents bus de communication pour optimiser au maximum la communication entre 2 DSPIC33EP512MU et les différents périphériques que j'utilise: Afficheur LCD, lecteur RFID, Carte bouton, Monnayeur...
1 carte gère l'affichage, carte bouton, monnayeur,gprs et différents moteurs ...
La deuxième gère principalement le lecteur rfid et communique en exe avec la 1ere carte.
On utilise la communication UART pour le monnayeur(mdb), lecteur rfid(exe), gprs (exe) et I2C pour l'afficheur et les cartes boutons.

Cependant il y a rarement (mais c'est très problématique quand même) des plantages au niveaux de l'i2c. J'ai mis en oeuvre des interruptions pour essayer de gérer ces erreurs mais vu que les plantons sont tellement rares je ne sais pas si c'est réellement efficace. C'est pourquoi j'essaye de voir d'autres communications (plus sécurisé au niveau des perturbations électromagnétiques)

J'aimerai avoir des renseignements aux niveaux des différents bus de communication qui pourraient surement m'aider pour éviter ces perturbations (perturbations dues surement aux changement de marches des différents moteurs et peut être de quelques lacunes de blindage au niveau des cartes électroniques).
Mon tuteur voulait que je me renseigne au niveau du bus USB mais je ne sais pas s'il vaudrait pas mieux que je me renseigne sur les bus CAN ou autres. J'aimerais avoir quelques explications concernant les différents BUS ou si vous aviez des doc sur c'est différents bus (j'ai recherché sur internet mais je ne trouve pas d'explications très détaillé qui me donne les avantages et inconvénients de chaque bus)

En espérant avoir était assez clair! N'hésitez pas à me demander d'avantages d'explications!

Cordialement,
Steyf65
-----

[invite638d5238]

Bonjour,
Es-tu sur que c'est bien la liaison qui pause problème et non l'envoi d'une mauvaise commande ?
Est-ce qu'il y a un point commun à tous les beugs et à quelle fréquence se répètent-t'il ?
Comment fais-tu pour faire repartir le système ?

Dans ce genre de cas j'aurais tendance à te dire d'essayer de détecter le beug et de traiter via le DSPIC, peut-être avec les ACK par exemple. Changer de liaison te fera changer beaucoup de chose, hardware et software

[invite826167ad]

Bonjour Flo7374 et merci d'essayer de m'aider!

En gros 1 fois sur 1000 voir plus pour le bug.
En quelque sorte c'est un plantage au niveau de l'afficheur ou des cartes boutons (on a pas pu le voir nous même car en faisant de nombreux tests on a pas réussi à reproduire le bug) et ça fait planter le système entier donc plus rien ne fonctionne sauf le monnayeur qui le continue à prendre les pièces mais ne les rends pas (donc c'est très embêtant). Le seul moyen est de couper l'alimentation générale et de la remettre pour que tout se réinitialise. Ce qui est sur c'est que ça provient de la communication i2c.
J'ai mis en oeuvre des interruptions pour gérer ça ainsi qu'un watchdog qui resetera tout les périphériques (mais cela sera opérationnel pour les prochaines cartes) car pour le moment ils n'utilisaient pas les pins reset des différents peripheriques...

[invite638d5238]

D'accord, je comprend mieux.
C'est vrai que la rareté du beug rend pas les choses faciles !

As-tu des longueurs de cable significativement différentes ? L'horloge se désynchronise peut-être au bout d'un certain temps ..
Est-ce que le beug arrive en laissant tourner le système seul ou après une manipulation ?

Pourrais-tu faire un schéma de ton système ?

(Ca fais beaucoup de question ^^)

[A voir en vidéo sur Futura]

[invite826167ad]

Merci pour ton aide FLO7374

En ce qui concerne la longueur des câbles : pour l'afficheur (10cm)
pour la carte bouton (70cm)
Le problème viendrait du câble de la carte bouton
Le problème arriverait en laissant tourner le système (problème constaté sur une machine placé en exterieur)

Je t'envoi le schéma de la carte bouton

[inviteede7e2b6]

un anti-rebond (soft ou hard) devrait régler le probléme.

[invite826167ad]

Je me suis peut-être mal exprimé. Le problème ne vient pas des boutons eux mêmes (anti-rebond déjà mis en oeuvre) mais de la laison I2C avec le MCP23017 qui gère les leds.

[invite638d5238]

Merci pour les schéma
Du coup je comprend mieux ton système.

Corrige moi :
De ton PC, tu envoi des infos sur le MCP23017 , qui plante même sans rien faire.

As tu la possibilité de déconnecter les ports du MCP23017, et de lui envoyer des commandes bidons ? (genre faire une compteur etc ...) Ca permettrait d'être sur que le problème viens de l'I2C.

Sinon, es-tu sur que le MCP parvient à charger correctement les 70cm de câbles ?
Le problème

[invite826167ad]

Merci FLO7374

Ce n'est pas le pc qui envoi des infos mais une carte CPU avec un DSPIC33EP512MU (c'est lui qui envoi les infos) au mcp23017 ainsi qu'a d'autres péripheriques.
Lorsque le plantage a eu lieu (ne s'est pas reproduit depuis quelques mois), le seul moyen a été de changer le câble qui relie la carte cpu à la carte bouton. Ils avaient éteint puis rallumé la machine, le plantage se reproduisait au bout d'un moment, changé la carte bouton => idem, changé la CPU => idem et le seul moyen a été de changer la câble.

Oui il y a la possibilité de déconnecter les ports du MCP => pas de problème constaté

Par contre je en sais pas s'il parvient bien à changer les 70cm du câble mais ce plantage n'est arrivé que quelques fois ( je crois 2 ou 3fois) et la solution a été de changer le câble.
Donc soit le câble été défectueux soit.... je ne sais pas.
Est ce qu'il ne faudrait pas utiliser une communication qui serait moins sensible aux parasites et à la longueur de câble?

[invite638d5238]

D'accord, pardon de te faire répéter! En effet c'est un plantage assez lent !

Quelle est ce type de câble ?

Il existe beaucoup de type de bus de com , dont des robustes. Le problème est que les protocoles logiciels et physiques qu'ils entraînent te feront changer un bout de ta chaîne. Renseigne toi sur ce que le DSPIC peut utiliser mais je crains qu'à part I2C et SPI ....

Demande toi quel est ton degré de liberté, quels sont les maillons fixes et ceux sur lesquels tu peux changer les choses

[invitefa96bd8f]

Tu as tes résistances de pull sur toutes tes entrées ?

Ton I2c c'est entre tes deux PIC ? J'ai un peu de mal à suivre

[invite826167ad]

Merci FLo7374!
Tu n'as pas à t'excuser, c'est déjà bien que tu veuilles m'aider!^^
Le câble est un 24mm² multi-brin souple.
Le dspic que j'utilise (en l'occurence DSPIC33EP512MU810) possède 4 UART, 4 SPI, 2 I2C, 2 CAN et 1 USB.
Pour le moment on utilise seulement l'UART et l'I2C

Merci Terriblement! Le soucis se pose au niveau de la communication I2C entre un DSPIC33EP512MU810 et un MCP23017 (c'est la que ça plante)
La communication entre les 2 DSPIC sert surtout pour gérer d'un coté le lecteur RFID et pourvoir communiquer avec l'autre DSPIC qui lui gère la carte bouton (c'est la ou il y a le soucis) le monnayeur, les différents moteur etc...
En ce qui concerne les résistances de pull up, oui on en utilise sur toutes les entrés en les mettant en série et on utilise aussi des résistances de tirages.
J'espère que je suis clair, si ce n'est pas le cas n'hésitez pas à me le dire!
Merci encore de bien vouloir m'aider!!!