Microb Technology/2008/meetings/report-2007-06-30

Current page: Microb_Technology / 2008 / meetings / report-2007-06-30

Compte rendu de la réunion du 30 juin 2007

Etaient présents:

• Fabrice
• Olivier

Info

Toujours sur l'i2c, nous commençons à mettre en place le code coté maître et esclave. Nous avons retenu une solution avec 1 MASTER et 1 ou plusieurs SLAVEs, plutôt qu'une solution MULTIMASTER, car elle simpifie le séquencement du code et donnera quelquechose de plus déterministe. Dans la solution choisie, le maitre est le seul a pouvoir initier une communication. Cela signifie qu'il faut mettre en place un polling de chaque esclave, à faire régulièrement.

Lorsque le maitre envoie une commande n'exigeant pas de réponse, on peut le faire à tout moment en utilisant i2c_send_sync() ou i2c_send(). La première permet de retourner directement le résultat (elle doit être appelée depuis un contexte où les interruptions sont autorisées), alors que la seconde retournera le statut final dans un callback. Il faut encore modifier un peu i2c_send_sync() pour utiliser un flag de status plutôt qu'une modification du pointeur send_event. Ce type de commande ne necessitant pas de réponse de l'esclave (par exemple pour commander une action immédiate comme le tir d'une balle) ne modifie pas le buffer d'emission de l'esclave.

Pour les commandes exigeant une réponse (demande de statut), il est nécessaire que le type de donnée transporté soit présent dans la trame de réponse, car le traitement de la réponse est fait de manière complètement asynchrone. Le maître effectuera des pollings pour ces commandes dans un seul "thread". C'est à dire que l'ordre de ces commandes sera fixe (la commande de lecture suivra forcément la demande associée), et mettra à jour des variables locales qui seront utilisées dans le programme principal. Certaines valeurs pourront être demandées plus souvent que d'autres.

Statut

• Pour le moment on a un blocage dans le code dont la raison n'est pas évidente. Suite la prochaine fois.