continuez à me soumettre des idées, je suis preneur !
A mon avis le choix du bus n'est pas anodin, et tu devrais te poser la question suivante :
- est-ce que les équipements sur le bus auront besoin d'émettre des messages sans forcément être interrogés par le maitre, et sui les esclaves devront dialoguer entre eux.
Si c'est oui, il vaut mieux passer par un bus de type CAN qui n'a pas de principe maître/esclave, mais tout le monde peut émettre des messages sur le bus. L'inconvénient, c'est un peu plus cher. l'avantage ; tu n'as pas à te prendre la tête avec des histoires de maitre/esclave et tout le monde peut communiquer avec tout le monde.
Dans le cas d'un bus maître/esclave, il te faudra pooler sans cesse les équipements de ton bus. Le bus I2C a un mode multimaitre mais tu ne peux pas multiplier les maitres à l'infini, et je ne me rappelle plus comment se passe le dialogue de maître à maitre (ni même si c'est possible) : je vais voir si j'ai encore des docs sur le sujet. Pour le modbus, il y a un seul maître de bus me semble-t-il.
Dans le cas ou tu as un seul maitre et des esclaves qui doivent discuter entre eux, il te faudra gérer la communication entre esclaves. Il me semble que durant mes études, j'avais fait un TP comme ça sur Modbus, avec un protocole à base de jeton que le maître envoyait tour à tour à chaque esclave (le maitre ne faisait que ça, gestion des communications et non-réponse des esclaves). Chaque esclave répondait au maître en supprimant les messages qui lui étaient destinés et en ajoutant ceux qu'il voulait ajouter à destination des autres esclaves. Je pense que ce genre de protocole sera difficile à réaliser avec I2C, ou les messages échangés sont plus ou moins imposés par l'état des composants sur le bus.
[^] # Re: Module wifi ou bus de type CAN ou mieux adapté à la domotique ?
Posté par totof2000 . En réponse au message Des Arduinos sur un bus USB, un serveur de domotique, et une interface de contrôle REST. Évalué à 2.
A mon avis le choix du bus n'est pas anodin, et tu devrais te poser la question suivante :
- est-ce que les équipements sur le bus auront besoin d'émettre des messages sans forcément être interrogés par le maitre, et sui les esclaves devront dialoguer entre eux.
Si c'est oui, il vaut mieux passer par un bus de type CAN qui n'a pas de principe maître/esclave, mais tout le monde peut émettre des messages sur le bus. L'inconvénient, c'est un peu plus cher. l'avantage ; tu n'as pas à te prendre la tête avec des histoires de maitre/esclave et tout le monde peut communiquer avec tout le monde.
Dans le cas d'un bus maître/esclave, il te faudra pooler sans cesse les équipements de ton bus. Le bus I2C a un mode multimaitre mais tu ne peux pas multiplier les maitres à l'infini, et je ne me rappelle plus comment se passe le dialogue de maître à maitre (ni même si c'est possible) : je vais voir si j'ai encore des docs sur le sujet. Pour le modbus, il y a un seul maître de bus me semble-t-il.
Dans le cas ou tu as un seul maitre et des esclaves qui doivent discuter entre eux, il te faudra gérer la communication entre esclaves. Il me semble que durant mes études, j'avais fait un TP comme ça sur Modbus, avec un protocole à base de jeton que le maître envoyait tour à tour à chaque esclave (le maitre ne faisait que ça, gestion des communications et non-réponse des esclaves). Chaque esclave répondait au maître en supprimant les messages qui lui étaient destinés et en ajoutant ceux qu'il voulait ajouter à destination des autres esclaves. Je pense que ce genre de protocole sera difficile à réaliser avec I2C, ou les messages échangés sont plus ou moins imposés par l'état des composants sur le bus.