Casse-tête.

Le 13/10/2011 20:04, jj a écrit :

adresse, il

Redondance n fois, avec un filtrage hardware aigu à la réception du retour, est-il ou non possible que se reproduise indéfiniment une parfaite simultanéité? Peut-être que c'est insoluble et si pas moyen de différencier, est-ce vital? JC ne dit pas la nature des données à envoyer.

Une mauvaise solution: continuer l'écoute pour situer l'esclave en analysant ce pourquoi il transmet, je suppose que le maitre attend en silence que l'esclave prenne l'initiative de transmettre.

--
capfree  -

jj a tapoté du bout de ses petites papattes :

Si on module les bits en fréquence, le risque de non-détection d'une collision diminue grandement.

--
LeLapin

On 13 oct, 19:32, jj

Si, parce-que deux signaux superpos=E9s sur un m=EAme bus "corruptent" la trame : la superposition d'au moins deux signaux implique que les bits recus ne sont plus coh=E9rents avec le format du protocole, la trame sera donc rejet=E9e ( et de plus de CRC sera faux )

r)

nse,

Ok, bien vu le coup du =AB sans se chevaucher =BB ! Mais d=E9ja pris en compte dans mon tout premier post : | Ni le maitre ni aucun esclave n'envoient de trame | sur le bus si celui-ci est d=E9ja occupp=E9. Donc, dans le cas o=F9 un premier esclave a r=E9pondu au maitre, aucun des autres esclaves n'=E9mettront. On retrouve les deux seuls cas possibles :

1=B0) Un esclave r=E9pond avant les autres : le N=B0 lui sera attribu=E9. 2=B0) Plusieurs esclaves r=E9pondent : collision, rejet, r=E9it=E9ration.

ast,

Oui mais seulement lors de la phase d'installation, pendant la num=E9rotation. Une fois tous les num=E9ros attribu=E9s, on passe en phase d'exploitation et cet algo n'est plus actif puisque tous les num=E9ros ont =E9t=E9 attribu=E9s. ( j'ai l'impression de me r=E9p=E9ter, mais on m'a dit que je radotais ;o)

Je ne vois pas pourquoi tu dis que les collisions ne sont pas d=E9tect=E9es ... elles le sont.

Ah, une propo d'algo ! :o) C'est =E0 creuser, mais je pr=E9f=E8re coller au standard maitre/esclave qui veut qu'un esclave n'=E9mette que si le maitre lui a explicitement demand=E9. Sinon la probabilit=E9 de collision monte en fl=E8che.

r le double adressage.

ame

C'est une des raisons qui font qu'une collision implique

*n=E9c=E9ssairement* le rejet des trames collisionn=E9es : vu du (des) r=E9cepteur(s), des trames superpos=E9es corruptent le format du protocole, m=EAme sans CRC. Et l=E0 il y a en plus un CRC.

Il y a un CRC :o)

On 13 oct, 20:04, jj

Une collision implique le rejet total de l'=E9change. Donc cette objection ne tient pas.

- On est d'accord, ou pas ?

On 13 oct, 21:05, LeLapin

Le support est une paire ... de 3 fils :o) RS485 standard avec signal diff=E9rentiel (+ masse) pour am=E9liorer le RSB et diminuer le TEB.

Donc : collision =3D> corruption =3D> rejet =3D> r=E9it=E9ration.

On 13 oct, 19:51, capfree

Pas la peine, parce-que si plusieurs r=E9ponses alors collision donc annulation puis r=E9it=E9ration.

( là, on tourne en rond ... )

Ce qui me gêne, même hard, soft ca c'est courant et n'est pas grave, même fonctionnalité a la limite pourquoi pas si ce sont eux qui gèrent leur truc et s'adressent a un serveur, mais en plus totalement esclave d'un process central la je tique un peu.

Ton maitre va s'adresser a des trucs choisis aléatoirement et leur dire de réaliser quelque chose, cela peut se comprendre sur une demande de process ou de calcul, mais si tu a une interface avec le monde réel, je ne vois pas.

C'est pourtant une topologie assez usit=E9e.

Non, ce n'est pas comme ca que ca marche.

Oui, je m'y attendais un peu :o) Les esclaves sont effectivement des unit=E9s de traitement d=E9port=E9es d'=E9v=E8nements physiques, et sont r=E9guli=E8rement scann=E9s par le mait= re. De plus, il y a plusieurs de ces r=E9seaux, dont tous les maitres sont sur un autre bus - distinct - reli=E9 =E0 un PC ( disons-le comme ca )

Bon, c'est normal que quand le cahier des charges n'est pas enti=E8rement d=E9voil=E9, il y ait des mecs qui posent des questions aussi l=E9gitimes que g=EAnantes ! Mais bon, si je ne peux vraiment pas entrer dans le d=E9tail, je sais aussi que certains connaissent ce genre de situation. Donc, si vous l'acceptez, on reste sur ce sous-ensemble, juste histoire de valider/infirmer ce rogntudju d'algorithme, ou d'en proposer un autre, ok ? Parce-que j'ai d'autres questions en suspens ...

On 13 oct, 20:41, capfree

etour,

Le filtrage hard se fait de lui-m=EAme lors d'une collision sur le bus. Le filtrage soft se fait par CRC.

Non, gr=E2ce au d=E9lai al=E9atoire avant r=E9ponse. ( en toute rigueur ca reste =E0 prouver math=E9matiquement, mais m=EAme si ce n'est pas totalement impossible la probabilit=E9 reste suffisamment faible pour l'appli )

Ca ne tient pas, vu le rejet des collisions (m=EAme partielles) et la pr=E9sence d'un CRC.

Dans cette phase, la donn=E9 transmise est le num=E9ro =E0 attribuer =E0 un esclave n'en ayant pas encore. Ce num=E9ro est encapsul=E9 dans une trame soumise =E0 un format et un protocole.

Mais il est vrai que si la trame n'=E9tait compos=E9e que de donn=E9es brutes, sans format ni CRC, vu du r=E9cepteur les collisions ne seraient pas d=E9tectables. ( ce qui n'est pas le cas ici )

Non, c'est le contraire ( vois les posts pr=E9c=E9dents ) C'est le maitre qui s'adresse aux esclaves, les esclaves ne prennent JAMAIS l'initiative d'envoyer un message SAUF en r=E9ponse =E0 une requ=E8te explicite du maitre.

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

Je crois que le point qu'ont soulevé certains est que si 2 (ou plus) cartes répondent EXACTEMENT en même temps (d'autant plus probable que le bitrate est faible comparé à l'horloge proc de chaque carte, et que le soft est simple et que l'évènement d'une requète du maitre génère une interruption sur le proc des esclaves et ne soit pas gérée par du polling), et qu'elles répondent la même chose (ce qui est normal puisqu'elles sont identiques, hard et soft), ce qui inclut évidemment le CRC, il sera impossible de le détecter : mêmes fronts ou presque, mêmes états logiques des bits...

J'avais proposé de moduler les bits en FSK avec une porteuse assez élevée à horloge indépendante sur chaque carte (on introduit donc un décalage aléatoire, voire une légère différence de fréquence), ce qui provoquerait, en cas de collision, une modulation bizarre facile à détecter en mesurant par ex. le rapport cyclique. Sans être fiable à

100% (bien que sûrement très fiable si la modulation est à assez haute fréquence), c'est déjà bien plus sûr.

Me comprends-tu ?

--
LeLapin

On 13 oct, 23:01, LeLapin

Oui, tout =E0 fait. Un bon exemple de worst-case. Effectivement je n'avais pas compris cela.

Oui, pas mal :o) Mais le fait est que le bus est d=E9ja en RS485, et que ca, je n'y peux rien.

5/5

Apr=E8s r=E9flexion, si on part sur un d=E9bit de

115,2 kbps la dur=E9e d'un bit est d'environ 8,7 us et =E0 cette =E9chelle de temps je doute sinc=E8rement que deux UARTS puissent =EAtre parfaitement synchronis=E9s =E0 ce point-l=E0. Leur horloge d=E9rive du quartz du uP suivi de diviseurs, et m=EAme s'ils tol=E8rent quelques % sur la fr=E9quence nominale, ( =E0 cette heure-ci je n'ai pas le courage de calculer ca ) =E0 vue de nez la proba me semble (:op) tr=E9s faible. Qu'en penses-tu ?

Jean-Christophe avait énoncé :

Oui, mais à quel esclave ? Il y en aura plusieurs qui le prendront en compte.

Oui, c'est en général le principe des échanges maître/esclave.

Enfin si ce système prévu fonctionne, il faudra le faire breveter. Ce sera une première.

--
In gold we trust (c)

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

C'est pas négligeable. D'autant que comment génères-tu ton délai aléatoire ? Je suppose que c'est un algo standard pseudo-aléatoire. Mais quel est la valeur de départ ? Tu n'as aucun évènement réellement aléatoire pour démarrer ta séquence visiblement (clavier ou autre bouton). Et comme rien ne différencie les cartes esclaves, elles vont générer la même séquence de nombres pseudo-aléatoires...

--
LeLapin

On 14 oct, 17:15, LeLapin

ement

Bien vu : ca c'est effectivement LE truc qui coince !

La source pour la valeur de d=E9part ne peut pas =EAtre purement soft, il faut quelque chose d'externe.

Et si je branche une pinouille d'entr=E9e ADC sur une zener polaris=E9e dans son coude histoire d'avoir un bon niveau de bruit, et que je convertis cette tension en un entier qui servira de valeur de d=E9part : l=E0 j'aurais une proba tr=E9s faible d'avoir plus d'une carte qui d=E9marre sur la m=EAme valeur ?

une autre risque auquel je pense :

deux esclaves qui répondent juste l'un après l'autre sans se chevaucher, le maitre envoie alors une attribution d'adresse (en retour à la première réponse) que les deux esclaves vont prendre en compte ...

JJ

On 14 oct, 01:00, Jo Kerr

| la donn=E9 transmise est le num=E9ro =E0 attribuer | =E0 un esclave n'en ayant pas encore. | Ce num=E9ro est encapsul=E9 dans une trame | soumise =E0 un format et un protocole.

Au premier qui r=E9pond, sous condition de non-collision.

Non, et pour les raisons que j'ai d=E9ja d=E9crit plusieurs fois dans le d=E9tail.

Jusqu'=E0 maintenant, personne n'a d=E9montr=E9 que ca ne marchait pas : la plupart des contres-arguments sont construits sur la non-d=E9tection de collision (impossible puisque par nature une collision d=E9truit les donn=E9es des messages) ou sur une *parfaite* synchronisation de deux trames. ( si peu probable que c'est n=E9gligeable )

LeLapin a soulev=E9 un d=E9faut crucial, mais je *crois* avoir une r=E9ponse valable ...

On 14 oct, 18:08, jj

er,

Tu as d=E9ja propos=E9 ca dans ton post du 13/10 =E0 19h32

Et j'y ai r=E9pondu

| On 13 oct, 21:44, Jean-Christophe : | Ok, bien vu le coup du =AB sans se chevaucher =BB ! | Mais d=E9ja pris en compte dans mon tout premier post : | > Ni le maitre ni aucun esclave n'envoient de trame | > sur le bus si celui-ci est d=E9ja occupp=E9. | Donc, dans le cas o=F9 un premier esclave a r=E9pondu au maitre, | aucun des autres esclaves n'=E9mettront.

On 14 oct, 18:22, Jean-Christophe

cher,

D=E9sol=E9 JJ, je me suis mal exprim=E9 : Quand un esclave voit passer une trame d'un autre esclave en r=E9ponse =E0 la requ=E8te du maitre, il voit bien qu'il a =E9t=E9 grill=E9, donc il sort de son d=E9lai avant =E9mission, il n'=E9mettra rien du tout, et laisse tomber sa tentative. ( jusqu'=E0 la prochaine requ=E8te du maitre )

On 14 oct, 17:59, Jean-Christophe

llement

Il y a m=EAme plus simple sans zener ni ADC : lire un free running timer interne au uP. A la mise sous tension des cartes leurs mont=E9es de tension respectives ne peut pas se faire exactement en m=EAme temps ( =E0 l'=E9chelle de temps du cycle d'horloge ) Donc, m=EAme =E0 quelques ms pr=E8s, des compteurs 32 bits qui tournent =E0 quelques dizaines de MHz auront forc=E9ment des valeurs tr=E9s diff=E9rentes ... ok ?