choix de bus et protocole

[alainav1]

Bonjour,
je gère un circuit miniature (trains ) en particulier la commande des différents éléments( commande sons tension des cantons se fait par une commande infrarouge;(la zapette de tv commande les aiguillages accessoires .. au lieu de commander le changement de chaine , ça tombe bien y a rien à la télé ce soir !!)
ça marche tres bien en particulier parce que 2 ordres ne sont pas donnés en même temps .
Je me propose de récupérer des infos du circuit (présence de train sur un canton ...) sur l'entré d'un µP (pic 16FXX ou d'un arduino ?)
le probleme qui se pose c'est comment faire pour recuperer 2 infos émises en même temps .(par exemple un train rentre dans le canton 2 et un autre entre dans le canton 5 )
pouvez vous me donner une piste pour résoudre ce problème ?
quel bus utiiser (le circuit mesure environ 15m de long )?
quel protocole utiliser ? (les actions à mémoriser ne sont émise par un contact sec )
cordialement
Alain
-----

[vincent66]

Bonjour Alain,
Ah la rétrosignalisation, vaste débat...!
Etudiant la question actuellement avec un ami en vue de la prochaine réalisation d'une maquette nous avons opté pour du RS485 sur doubles paires torsadées blindées...
Il nous faudra établir un protocole pour éviter les collisions lors de la simultanéité de deux signalisations mais ça ne sera pas la mer à boire, nous intégrerons en hard et soft la capacité d'"écouter" si une transmission a déjà lieu entre un esclave et le maître...
Depuis le temps il doit être fabuleux ton circuit...

[alainav1]

Bonjour,

Depuis le temps il doit être fabuleux ton circuit.

ceux sont les circuits du club

pour plus d'info
http://ffmf.nord.free.fr/pagesclubs/...xpo2005-03.htm
http://www.les-ferrovipathes-du-calaisis.fr/index.php en cours de construction
si vous " travaillez " sur le protocole et si vous pouvez fournir le principe "anti collision " je suis preneur ?
cordialement
Alain

[jiherve]

bonsoir,
il ne peut y avoir de principe anti collision mais une methode de résolution des collisions, l'autre solution est un bus avec un contrôleur de bus qui donc en est le maitre et interroge les abonnés tour à tour c'est une solution simple et deterministe.
Bus à collision : RS485,CAN,ETHERNET
Bus sans collision : tous les bus aéronautique ARINC xx , MIL 1553 et Flexray ou TTP (bus à slot temporels)
JR

[A voir en vidéo sur Futura]

[vincent66]

Eh bien on oublie le principe du polling, interrogation des esclaves par le maître tour-à-tour...
On limite le temps d'une transaction à disons 100ms et on dote chaque esclave de la capacité de détecter une transaction en cours...
Si une transaction est détectée on réessaie 100ms plus tard...
Seul l'esclave peut détecter une collision, en captant ce qu'il a essayé de transmettre, si collision il réessaie 100ms plus tard...
Système vite saturé si 36 esclaves essaient simultanément de signaler un événement mais stastiquement jouable s'il n'y en a que deux ou trois...

[bobflux]

Le bus CAN fait ce que tu veux, inutile de réécrire une couche anti-collision par dessus le RS485, puisque le CAN fait déjà tout ça.

En gros, quand deux bidules parlent en même temps sur le bus, ils le détectent, et celui auquel tu as assigné la priorité la plus basse se tait, attend que l'autre ait fini, et retente sa chance.

Voir chez NXP les LPC11C24, idem chez grochip et les épiciers d'en face.

Bien sûr, un bidule trop bavard peut monopoliser le bus, à toi de faire attention. Utilise des messages courts et ne transmets que lorsque c'est pertinent.

[jiherve]

Bonsoir
C'est bien le drame avec le CAN un gros bavard et tout est par terre, mais avec Ethernet c'est pareil d'où l'AFDX.
JR