Casse-tête.

Le 11/10/11 22:49, Jean-Christophe a écrit :

Quand un serveur DHCP attribue les IP dans un réseau ethernet, l'identification des paquets se fait sur l'adresse MAC de la carte réseau. Dans ton cas, si plusieurs esclaves répondent presque en même temps comment vont ils savoir à qui la réponse du master est adressée? Pendant la procédure d'attribution du numéro il faudrait que les esclaves signent leur paquet (avec un checksum aléatoire ou autre) et que le master renvoie cette signature dans sa réponse.

Julien Arlandis a tapoté du bout de ses petites papattes :

Elle est adressée au premier qui répond si j'ai bien compris. Donc aucune ambigüité. S'il y a chevauchement, donc collision, toutes les cartes la détectent, annulent, et la procédure recommence.

Moi je ne vois pas de faille, mais je trouve ça lent et compliqué. En plus, ça n'est utile/possible que si toutes les cartes sont les mêmes et n'ont pas d'entrées/sorties spécifiques (ou alors il faut une deuxième passe de la carte maitre pour interroger toutes les cartes esclaves par leur numéro pour leur demander ce qu'elles font et/ou à quoi elles sont connectées, ce qui complique encore un peu plus).

On peut savoir à quoi c'est censé servir ?

--
LeLapin

On 11 oct, 23:12, Julien Arlandis

Oui, mais ici toutes les cartes esclaves sont identiques, le hard et le soft sont tous les m=EAmes ( prod s=E9rie ) et on a aucun moyen de les discerner : pas de strap ni de puce ayant un identifiant unique.

A moins que je n'ai pas compris ton objection (?) ce cas est d=E9ja pris en compte :

| 1=B0) Plus d'un esclave r=E9pond en m=EAme temps : | il y a collision, la trame est perdue, le num=E9ro | courant n'est pas attribu=E9, et le maitre r=E9it=E8re.

Mon protocole de com inclut bien un CRC16 pour v=E9rification de non-corruption des trames recues.

On 11 oct, 23:30, LeLapin

C'est bien ca.

Si ca tourne (par exemple) =E0 115 kbps et qu'on a des time-out assez courts, ces trames-l=E0 ne prendront pas plus de 8 octets, etc. On laisse le truc tourner dans son coin pendant qu'on fait autre chose d'utile. L'important est que l'algo finisse =E0 coup s=FBr par attribuer un num=E9ro unique =E0 chaque carte. ( bon, ok, l=E0 je d=E9fends ma cr=E8merie, mais si tu as une id=E9e, on en discute :o)

Aucun probl=E8me : une fois les num=E9ros attribu=E9s, chaque carte peut ensuite r=E9pondre =E0 une demande d'identification via un code sp=E9cifique inclus dans le protocole.

C'est un sous-ensemble d'un truc plus vaste pour une =E9tude pro alors d=E9sol=E9 de ne pouvoir d=E9tailler le reste. Mais en gros voil=E0 le topo, qui reste assez g=E9n=E9rique : un bus, du monde dessus, et l'id=E9e de param=E9trer le matos

*automatiquement* sans avoir un gus pour positionner des straps sur chaque carte, ni leur attribuer un num=E9ro en les branchant une par une sur le bus, etc. (bref : un bon algo, et les b=E9canes se d=E9merdent entre elles)

Jean-Christophe a tapoté du bout de ses petites papattes :

Minimum indispensable pour la détection de collision.

--
LeLapin

Le 11/10/2011 23:33, Jean-Christophe a écrit :

Comment se passe la détection d'une collision ? Le signal est détruit par interférences ?

Le 11/10/2011, Jean-Christophe a supposé :

Toute cette histoire est un peu aléatoire. Je m'explique: que se passe-t-il le jour où un module esclave tombe en panne? On le remplace (en plus il n'y a pas de switch à régler), mais quelle adresse va lui être attribuée ? S'il reçoit une nouvelle adresse, l'application côté maître doit être modifié. Comment ? Bref tout un tas de questions qui influent le système dans sa globalité. Pour avoir côtoyé divers systèmes maître/esclave (Profibus, Modbus/Jbus) les esclaves étaient toujours adressés avant mise en service. Leur adresse étant en rapport avec leur fonction dans le projet.

--
In gold we trust (c)

"Julien Arlandis"

Oui : le CRC sera faux donc la trame sera rejetée.

Dans le cas où plusieurs esclaves répondent en même temps, la collision entrainera le rejet de ces réponses, donc le maitre n'enverra même pas de confirmation, et réitérera le numéro courant non encore attribué.

"Jo Kerr"

Sur un groupe de N esclaves tous numérotés par le maitre, si on en remplace un seul, alors le numéro qui lui sera automatiquement attribué sera forcément le même. ( cela découle de l'algo décrit précédemment )

Il ne peut pas recevoir une adresse différente car toutes les autres N-1 adresses sont déja attribuées.

Pas à mon sens.

Oui, tout à fait.

Oui j'entends bien, mais ici le but est de numéroter automatiquement, et sans aucune intervention manuelle sur chacun des boitiers. Leur identification se fait après numérotation, et pour chaque carte le maitre peut donc identifier de quel type il s'agit ( sur ce sujet, voir ma réponse à LeLapin )

Jean-Christophe a tapoté du bout de ses petites papattes :

Ca simplifierait beaucoup si tu mettais une daisy chain.

--
LeLapin

"LeLapin"

. Mais ca allongerait sensiblement les temps de com avec les cartes situées en fin de chaine. Et la topologie existe déja : un seul bus avec tout le monde dessus, en parallèle. ( pas en série, Zarkon nous en protège )

Tant que le principe proposé est OK alors ca me va. Bien sûr, si quelqu'un a un autre algo à proposer, je suis preneur.

( j'ai d'autres questions à venir mais avant ca il faut déja valider/invalider ce point-là )

car toutes les autres N-1 adresses sont déja attribuées.

Et si tu en a deux qui crament simultanément ?

Cela implique que le nombre d'adresse possible soit identique au nombre de cartes, quelles soit dispo en permanence

De toute façon chaque carte va avoir une fonctionnalité et une seule sinon je ne vois pas comment cela peut marcher, donc tu va bien être obligé de leur mettre un codage fonctionnel fixe, qu'il soit sur programmable sur la carte ou en externe.

Et ton maitre quelle adresse ? Il lui en faut bien une

« voici un numéro, qui en veut ? »

Non, imagine que tu allume une carte sup ou qu'il y ai un plantage sur une comment le maitre va le savoir pour lui proposer une adresse ?

Respecte le protocole DHCP ( tu peux le simplifier puisque tu n'aura qu'un seul serveur ), ton client sans adresse contacte le maitre et lui demande une adresse avec sa fonction, le maitre propose une valeur d'adresse, le client lui accuse réception . Tu n'utilise pas de bail, pour simplifier les choses.

Pour la gestion des collisions de toute façon cela va être intégré dans ton protocole de comm standard, car je suppose que la comm peut être a l'initiative du maitre ou des clients, au besoin tu adapte tes trames pour une longueur fixe et un crc, au besoin tu t'inspire d'ethernet

Le 12/10/2011, Jean-Christophe a supposé :

Donc il y a une identification de chaque carte dans le logiciel embarqué. Pourquoi ne pas intégrer l'adresse esclave dans ce même logiciel (ça se fait) et on éviterait bien des problèmes et aléas.

--
In gold we trust (c)

Ce qui pr=E9c=E8de est ce que j'ai dit au tout d=E9but. ---- Ce qui suit est une r=E9ponse =E0 une supposition (fausse) faite par un intervenant : que les esclaves ne sont pas tous identiques.

Non - pour l'instant - ce sont toutes les m=EAmes.

Je r=E9p=E8te que les esclaves sont tous identiques : m=EAme hard, m=EAme soft.

On 12 oct, 14:32, "JP"

Et pourquoi pas 70 cartes qui crament en m=EAme temps ? Cela ne concerne pas la question pos=E9e, qui est d'assigner automatiquement un num=E9ro unique =E0 chaque esclave.

Le maitre maintient une table du nombre de cartes trouv=E9es, et les correspondances index->num=E9ro.

Pour l'instant, chaque carte esclave est identique, je l'ai d=E9ja dit d=E8s le d=E9but. Si tu changes les termes de ma question, ta r=E9ponse n'y r=E9pond plus. ( je comprends ton contre-argument, mais il n'est pas de mise pour l'instant )

Nous sommes donc d'accord (pour l'instant)

Non.

Sur le bus maitre/esclaves, le maitre n'a pas besoin d'adresse, car il n'est jamais adr=E9ss=E9 par un esclave. Le maitre s'adresse aux esclaves, les esclaves ne prennent jamais l'initiative d'envoyer un message sur le bus SAUF en r=E9ponse =E0 une requ=E8te du maitre.

(ceci dit, au niveau sup=E9rieur de la hi=E9rarchie, chaque maitre de chaque sous-groupe d'esclaves est lui-m=EAme sur un autre bus reli=E9 =E0 un PC, mais cela ne concerne plus la question pos=E9e =E0 l'origine et on s'=E9loigne du sujet)

Non : lors de l'install sur site, on installe TOUTES les cartes sur le bus avant num=E9rotation.

Si une carte est plant=E9e elle ne r=E9pondra plus au requ=E8tes du maitre, qui saura donc que cette carte-l=E0 est HS. (et si elle est HS ca ne sert =E0 rien de tenter de lui r=E9attribuer un num=E9ro)

J'ai pos=E9 d=E8s le d=E9but la condition que chaque esclave est rigoureusement identique. Donc pas d'identifiant hard ni soft.

Le 12/10/2011, Jean-Christophe a supposé :

Ok, mais comment se distinguent-ils, ou comment sont-ils "identifiés"? Car tu disais:

Ce qui laisse supposer qu'il y a des "types" différents.

--
In gold we trust (c)

On 13 oct, 11:15, Jo Kerr

| Je r=E9p=E8te que les esclaves sont tous identiques : | m=EAme hard, m=EAme soft.

Par le num=E9ro que le maitre leur attribue.

|| Leur identification se fait apr=E8s num=E9rotation, et pour chaque carte || le maitre peut donc identifier de quel type il s'agit

Ce qui pr=E9c=E8de est une r=E9ponse (malheureuse) =E0 une supposition (fausse) faite par un intervenant, qui proposait que les esclaves ne soient pas tous identiques : comme je l'ai dit au d=E9but du message auquel tu r=E9ponds !

Donc, les esclaves sont tous identiques : m=EAme hard, m=EAme soft. ( l=E0, on tourne en rond ... )

Pour l'instant le principe de num=E9rotation automatique tient la route. Bien s=FBr que si quelqu'un a un autre algo =E0 proposer, pour les m=EAmes conditions (tous esclaves identiques) je suis preneur.

Quand =E0 cet algo il reste une question : vaut-il mieux que les esclaves

- Attendent pendant une dur=E9e al=E9atoire comprise entre 0 et N-1.

- Ne r=E9pondent qu'avec une probabilit=E9 1/N.

(ca marche dans les deux cas, mais je suppose que l'un est plus rapide que l'autre)

Le 11/10/2011 22:49, Jean-Christophe a écrit :

Intéressant,

toutefois, il y a un risque que deux cartes prennent la même adresse, il n'y a pas détection de collision, deux esclaves répondant de façon assez proche (mais sans se chevaucher) pour que le maitre n'aie pas le temps de réagir à cette double réponse, et il attribue une adresse, en réponse au premier esclave, adresse que deux esclaves prennent en compte.

de plus ce système nécessite que le maitre fasse régulièrement des broadcast, encombrant la bande passante, et créant des collisions, qui ne sont pas détectées.

il serait plus simple que ce soit l'esclave qui envoie sa demande d?adresse au maitre qui lui réponde. Idéalement un identifiant unique doit être échangé afin d'éviter le double adressage. Ainsi l'occupation de la bande passante est minimisée.

Je reviens sur la notion de collision: il faut absolument mettre en place un mécanisme permettant de détecter les collisions, sinon la trame passera en étant déformée, ce qui est pire (par exemple si l'adresse est dans l'entête)

la détection de collision peut se faire en hard, comme sur ethernet, ou bien en mettant des sommes de contrôle pour contrôler l'intégrité des trames reçues.

JJ

Le 13/10/2011 19:32, jj a écrit :

Alors suivre la délivrance de l'ID d'une interrogation systématique par le maitre, si plusieurs réponses annulation.

--
capfree  -