EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

Casse-tête.

Nouveau sujet

elektroda.net NewsGroups Forum Index - Electronique FR - Casse-tête.

Goto page 1, 2, 3, 4, 5  Next

Jean-Christophe
Guest

Tue Oct 11, 2011 10:49 pm   



Bonsoir la foule,

Voici un petit problème intéréssant,
pas de l'électronique mais bon pour les méninges :
j'ai sur un bus un réseau de cartes
que je voudrais numéroter automatiquement.
(je vais tenter une description en mode télégraphique)

Soit un bus avec un maitre et N esclaves. Les échanges
se font via un protocole (genre JBUS) qui inclut le
numéro d'esclave [ 1...N ] auquel le maitre s'adresse,
et on réserve le numéro zéro pour s'adresser à tous.
Ni le maitre ni aucun esclave n'envoient de
trame sur le bus si celui-ci est déja occuppé.
(chaque esclave recoit toutes les trames, mais ne prend en
compte que celle qui lui est adressée par son propre numéro,
et dans ce cas il répond au maitre. Seule la trame de
numéro zéro sera prise en compte par tous les esclaves,
et dans ce cas aucun ne répond - sinon il y a collision)

Ceci étant posé, voici ce qu'il faut résoudre :
Sachant qu'à la toute première mise sous tension,
aucun esclave n'a de numéro, comment le maitre peut-il
attribuer à chacun un numéro unique dans [ 1...N ] ?

--------

J'ai pensé à cet algo :
le maitre envoie à tous les esclaves une trame signifiant
« voici un numéro, qui en veut ? »
Chaque esclave n'ayant pas encore de numéro répond
« moi je veux bien »,
le maitre renvoie un acknowledge signifiant :
« ok, alors garde-le »
puis passe au suivant.
L'astuce consiste à ce que chaque esclave, avant de répondre,
attende pendant une durée aléatoire comprise entre 0 et N-1,
(ou que chaque esclave ne réponde qu'avec une probabilité 1/N)
afin d'éviter les collisions avec une probabilité non nulle.

Deux cas possibles :

1°) Plus d'un esclave répond en même temps :
il y a collision, la trame est perdue, le numéro
courant n'est pas attribué, et le maitre réitère.

2°) Un esclave répond avant tous les autres :
les autres esclaves voyant passer sa trame se taieront,
le maitre recevra sa réponse et lui reverra l'acknowledge,
le numéro sera attribué,
le maitre passe à l'attribution suivante.

Même si l'attribution dépend du délai aléatoire
(ou de la proba en 1/N) nécéssaire à l'anti-collision,
pour une vitesse de bus assez élevée et un nombre
d'esclaves pas trop grand, après un temps fini 'T'
on atteindra TOUJOURS la limite où chaque esclave
présent sur le bus aura un numéro unique attribué.


Première question : vaut-il mieux que les esclaves :
- Attendent pendant une durée aléatoire comprise entre 0 et N-1.
- Ne répondent qu'avec une probabilité 1/N.


Seconde question : y a-t'il une faille dans cet algo,
qui ferait que ca ne fonctionne pas du tout,
ou est-ce que ca tient bien la route ?

Julien Arlandis
Guest

Tue Oct 11, 2011 10:49 pm   



Le 11/10/11 22:49, Jean-Christophe a écrit :
Quote:
Bonsoir la foule,

Voici un petit problème intéréssant,
pas de l'électronique mais bon pour les méninges :
j'ai sur un bus un réseau de cartes
que je voudrais numéroter automatiquement.
(je vais tenter une description en mode télégraphique)

Soit un bus avec un maitre et N esclaves. Les échanges
se font via un protocole (genre JBUS) qui inclut le
numéro d'esclave [ 1...N ] auquel le maitre s'adresse,
et on réserve le numéro zéro pour s'adresser à tous.
Ni le maitre ni aucun esclave n'envoient de
trame sur le bus si celui-ci est déja occuppé.
(chaque esclave recoit toutes les trames, mais ne prend en
compte que celle qui lui est adressée par son propre numéro,
et dans ce cas il répond au maitre. Seule la trame de
numéro zéro sera prise en compte par tous les esclaves,
et dans ce cas aucun ne répond - sinon il y a collision)

Ceci étant posé, voici ce qu'il faut résoudre :
Sachant qu'à la toute première mise sous tension,
aucun esclave n'a de numéro, comment le maitre peut-il
attribuer à chacun un numéro unique dans [ 1...N ] ?

--------

J'ai pensé à cet algo :
le maitre envoie à tous les esclaves une trame signifiant
« voici un numéro, qui en veut ? »
Chaque esclave n'ayant pas encore de numéro répond
« moi je veux bien »,
le maitre renvoie un acknowledge signifiant :
« ok, alors garde-le »
puis passe au suivant.
L'astuce consiste à ce que chaque esclave, avant de répondre,
attende pendant une durée aléatoire comprise entre 0 et N-1,
(ou que chaque esclave ne réponde qu'avec une probabilité 1/N)
afin d'éviter les collisions avec une probabilité non nulle.

Deux cas possibles :

1°) Plus d'un esclave répond en même temps :
il y a collision, la trame est perdue, le numéro
courant n'est pas attribué, et le maitre réitère.

2°) Un esclave répond avant tous les autres :
les autres esclaves voyant passer sa trame se taieront,
le maitre recevra sa réponse et lui reverra l'acknowledge,
le numéro sera attribué,
le maitre passe à l'attribution suivante.

Même si l'attribution dépend du délai aléatoire
(ou de la proba en 1/N) nécéssaire à l'anti-collision,
pour une vitesse de bus assez élevée et un nombre
d'esclaves pas trop grand, après un temps fini 'T'
on atteindra TOUJOURS la limite où chaque esclave
présent sur le bus aura un numéro unique attribué.


Première question : vaut-il mieux que les esclaves :
- Attendent pendant une durée aléatoire comprise entre 0 et N-1.
- Ne répondent qu'avec une probabilité 1/N.


Seconde question : y a-t'il une faille dans cet algo,
qui ferait que ca ne fonctionne pas du tout,
ou est-ce que ca tient bien la route ?

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.

LeLapin
Guest

Tue Oct 11, 2011 10:49 pm   



Julien Arlandis a tapoté du bout de ses petites papattes :
Quote:
Le 11/10/11 22:49, Jean-Christophe a écrit :
Bonsoir la foule,

Voici un petit problème intéréssant,
pas de l'électronique mais bon pour les méninges :
j'ai sur un bus un réseau de cartes
que je voudrais numéroter automatiquement.
(je vais tenter une description en mode télégraphique)

Soit un bus avec un maitre et N esclaves. Les échanges
se font via un protocole (genre JBUS) qui inclut le
numéro d'esclave [ 1...N ] auquel le maitre s'adresse,
et on réserve le numéro zéro pour s'adresser à tous.
Ni le maitre ni aucun esclave n'envoient de
trame sur le bus si celui-ci est déja occuppé.
(chaque esclave recoit toutes les trames, mais ne prend en
compte que celle qui lui est adressée par son propre numéro,
et dans ce cas il répond au maitre. Seule la trame de
numéro zéro sera prise en compte par tous les esclaves,
et dans ce cas aucun ne répond - sinon il y a collision)

Ceci étant posé, voici ce qu'il faut résoudre :
Sachant qu'à la toute première mise sous tension,
aucun esclave n'a de numéro, comment le maitre peut-il
attribuer à chacun un numéro unique dans [ 1...N ] ?

--------

J'ai pensé à cet algo :
le maitre envoie à tous les esclaves une trame signifiant
« voici un numéro, qui en veut ? »
Chaque esclave n'ayant pas encore de numéro répond
« moi je veux bien »,
le maitre renvoie un acknowledge signifiant :
« ok, alors garde-le »
puis passe au suivant.
L'astuce consiste à ce que chaque esclave, avant de répondre,
attende pendant une durée aléatoire comprise entre 0 et N-1,
(ou que chaque esclave ne réponde qu'avec une probabilité 1/N)
afin d'éviter les collisions avec une probabilité non nulle.

Deux cas possibles :

1°) Plus d'un esclave répond en même temps :
il y a collision, la trame est perdue, le numéro
courant n'est pas attribué, et le maitre réitère.

2°) Un esclave répond avant tous les autres :
les autres esclaves voyant passer sa trame se taieront,
le maitre recevra sa réponse et lui reverra l'acknowledge,
le numéro sera attribué,
le maitre passe à l'attribution suivante.

Même si l'attribution dépend du délai aléatoire
(ou de la proba en 1/N) nécéssaire à l'anti-collision,
pour une vitesse de bus assez élevée et un nombre
d'esclaves pas trop grand, après un temps fini 'T'
on atteindra TOUJOURS la limite où chaque esclave
présent sur le bus aura un numéro unique attribué.


Première question : vaut-il mieux que les esclaves :
- Attendent pendant une durée aléatoire comprise entre 0 et N-1.
- Ne répondent qu'avec une probabilité 1/N.


Seconde question : y a-t'il une faille dans cet algo,
qui ferait que ca ne fonctionne pas du tout,
ou est-ce que ca tient bien la route ?

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?

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

LeLapin
Guest

Tue Oct 11, 2011 10:56 pm   



Jean-Christophe a tapoté du bout de ses petites papattes :
Quote:
Mon protocole de com inclut bien un CRC16 pour
vérification de non-corruption des trames recues.

Minimum indispensable pour la détection de collision.

--
LeLapin

Jean-Christophe
Guest

Tue Oct 11, 2011 11:33 pm   



On 11 oct, 23:12, Julien Arlandis

Quote:
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.

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


Quote:
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?

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

| 1°) Plus d'un esclave répond en même temps :
| il y a collision, la trame est perdue, le numéro
| courant n'est pas attribué, et le maitre réitère.


Quote:
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.

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

Jean-Christophe
Guest

Wed Oct 12, 2011 12:05 am   



On 11 oct, 23:30, LeLapin

Quote:
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.

C'est bien ca.

Quote:
Moi je ne vois pas de faille, mais je trouve a lent et compliqu .

Si ca tourne (par exemple) à 115 kbps et qu'on a des time-out assez
courts,
ces trames-là 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 à coup sûr par attribuer un numéro
unique à chaque carte.
( bon, ok, là je défends ma crèmerie, mais si tu as une idée, on en
discute Surprised)

Quote:
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).

Aucun problème : une fois les numéros attribués,
chaque carte peut ensuite répondre à une demande d'identification
via un code spécifique inclus dans le protocole.

Quote:
On peut savoir quoi c'est cens servir ?

C'est un sous-ensemble d'un truc plus vaste pour une
étude pro alors désolé de ne pouvoir détailler le reste.
Mais en gros voilà le topo, qui reste assez générique :
un bus, du monde dessus, et l'idée de paramétrer le matos
*automatiquement* sans avoir un gus pour positionner
des straps sur chaque carte, ni leur attribuer un numéro
en les branchant une par une sur le bus, etc.
(bref : un bon algo, et les bécanes se démerdent entre elles)

Julien Arlandis
Guest

Wed Oct 12, 2011 8:40 am   



Le 11/10/2011 23:33, Jean-Christophe a écrit :
Quote:
On 11 oct, 23:12, Julien Arlandis

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.

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


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?

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

| 1°) Plus d'un esclave répond en même temps :
| il y a collision, la trame est perdue, le numéro
| courant n'est pas attribué, et le maitre réitère.

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

Jo Kerr
Guest

Wed Oct 12, 2011 8:49 am   



Le 11/10/2011, Jean-Christophe a supposé :
Quote:
On 11 oct, 23:12, Julien Arlandis

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.

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


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?

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

1°) Plus d'un esclave répond en même temps :
il y a collision, la trame est perdue, le numéro
courant n'est pas attribué, et le maitre réitère.


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.

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

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)

Jean-Christophe
Guest

Wed Oct 12, 2011 10:02 am   



"Julien Arlandis"

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

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é.

Jean-Christophe
Guest

Wed Oct 12, 2011 10:14 am   



"Jo Kerr"

Quote:
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 ?

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 )

Quote:
S'il reçoit une nouvelle adresse,

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

Quote:
l'application côté maître doit être modifié. Comment ?
Bref tout un tas de questions qui influent le système dans sa globalité.

Pas à mon sens.

Quote:
Pour avoir côtoyé divers systèmes maître/esclave (Profibus, Modbus/Jbus)
les esclaves étaient toujours adressés avant mise en service.

Oui, tout à fait.

Quote:
Leur adresse étant en rapport avec leur fonction dans le projet.

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 )

LeLapin
Guest

Wed Oct 12, 2011 11:15 am   



Jean-Christophe a tapoté du bout de ses petites papattes :
Quote:
"Jo Kerr"

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 ?

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 )

S'il reçoit une nouvelle adresse,

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

l'application côté maître doit être modifié. Comment ?
Bref tout un tas de questions qui influent le système dans sa globalité.

Pas à mon sens.

Pour avoir côtoyé divers systèmes maître/esclave (Profibus, Modbus/Jbus)
les esclaves étaient toujours adressés avant mise en service.

Oui, tout à fait.

Leur adresse étant en rapport avec leur fonction dans le projet.

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 )

Ca simplifierait beaucoup si tu mettais une daisy chain.

--
LeLapin

Jean-Christophe
Guest

Wed Oct 12, 2011 11:38 am   



"LeLapin"

Quote:
Ca simplifierait beaucoup si tu mettais une daisy chain.
..

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à )

JP
Guest

Wed Oct 12, 2011 12:32 pm   



Quote:
Il ne peut pas recevoir une adresse différente
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.


Quote:
et on réserve le numéro zéro pour s'adresser à tous.

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


Quote:
le maitre envoie à tous les esclaves une trame signifiant
« 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

Jo Kerr
Guest

Wed Oct 12, 2011 2:24 pm   



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

Quote:
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 )

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)

Jean-Christophe
Guest

Wed Oct 12, 2011 7:10 pm   



On 12 oct, 16:24, Jo Kerr <jo.k...@jo.invalid> wrote:

Quote:
ici le but est de numéroter automatiquement,
et sans aucune intervention manuelle sur chacun des boitiers.

Ce qui précède est ce que j'ai dit au tout début.
----
Ce qui suit est une réponse à une supposition (fausse) faite
par un intervenant : que les esclaves ne sont pas tous identiques.

Quote:
Leur identification se fait après numérotation,

Donc il y a une identification de chaque
carte dans le logiciel embarqué.

Non - pour l'instant - ce sont toutes les mêmes.

Quote:
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.

Je répète que les esclaves sont tous identiques :
même hard, même soft.

Goto page 1, 2, 3, 4, 5  Next

elektroda.net NewsGroups Forum Index - Electronique FR - Casse-tête.

Nouveau sujet

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map Opony