Yep!
Je ne suis pas tout à fait d'accord sur la multiplication des arduinos...Je concois naturellement qui'il faut quelque-chose à l'autre bout pour interpréter les messages.
Gromain59, d'ailleurs, nous apporte une solution qui va à contrario, même si au demeurant, j'ai bien entendu son bêmol.
Il faut considérer que dans un système de communication multiple, les appels, traitements et retours d'information feront certainement appel à une gestion des latences rigoureuses. Les trains d'informations devront être entre-coupés d'attentes afin de libérer le bus le temps que se forme la réponse. De plus, Je choisirais plutôt une liaison 4 fils. Deux pour l'émission, deux pour la réception. Dans ce cas ci, les trains seront plus rapides, mais les attentes existeront toujours, l'arduino maître aura sa propre latence et il ne peut se passer des retours.
Si l'idée est de gérer 4 pièces par exemples, en sus du maestro, nous avons 5 arduinos à considérer avec chacunes sa propre vitesse d'execution, sa propre faculté à composer le message et l'envoyer. Vous me direz, qu'est-ce 50 ou 80 ms !!! Cependant, si l'on double les arduinos, je vous laisse deviner...(pas sûr que ce soit proportionnel en plus)
Gromain59 utilise le protocole UDP via une liaison ethernet 10Mbit. Mais que veut dire
les performances sont satisfaisantes.
et combien d'arduino as-tu sur ta nouvelle topologie ?? UDP = perte possible, qu'en est-il ???
Je suis persuadé que l'on est loin d'utiliser toutes les capacités du langage de programmation. Sans évoquer le multitâche (*qui n'existe pas en fait), je pense qu'il faut cependant s'en inspirer. La principale limitation de la plupart des micro-controleur se situe dans la gestion serie des tâches qui lui incombe, séquentielle, j'ai souvent mesuré les temps d'execution de mes programmes, pour voir, et j'ai été régulièrement surpris de constater que le programme mettait 3 fois plus de temps à dérouler sa boucle dés qu'il y a communication (en moyenne 30-40 ms).
Vous me direz qu'une arduino par tâche est plus rapide qu'une seule qui s'occupe de tout, cependant ce que vous gagnez en vitesse d'execution, vous risquez de le perdre en communication.
Pour en revenir à la programmation, il manque plusieurs chose pour optimiser la gestion des tâches. Premièrement, il faut établir des règles de priorités et des règles de décisions. Je m'entends, si deux informations arrivent en même temps ou à peu d'intervalle, une avec un priorité "0", l'autre "1" (ou 2, ou 3, etc), j'execute d'abord la première.
Secondement, il faut stocker ces tâches, les trier, les executer en utilisant une partie de la mémoire flash (rapide?) et en s'inspirant des règles du premièrement. Ainsi, on se rapprocherait du *préemptif que je suggérais plus haut. J'ai un ordre local et distant simultanément, je donne la priorité à l'ordre local. Le message y, arrivé aprés x, est plus important. Etc.
Pour ma part, je commence à envisager également une évolution de mon projet, je m'oriente plutôt sur une carte à deux microcontroleurs (ATMEGA644), avec règles de décision, priorités et délégations vers le second processeurs au cas par cas. Du simili-clustering ou par analogie avec les automates modernes, une tâche rapide et une seconde pour le reste. J'y vois comme avantage la proximité entre les deux processeurs, donc des temps de communication trés réduit, doublement de la force de calcul (si j'arrive à implémenter du vrai clustering), une plus grande réactivité face aux événements multiples.
Je commence à me documenter sur différents algos qui pourraient m'aider dans cette tâche. Je ne suis pas encore arrété sur le protocole "ethernet".
@+
Zoroastre.