AV/C 1394 ou comment péter les plombs...
Par Yomgui le vendredi 30 janvier 2009, 14:12 - Autres projets - Lien permanent
Alors que Hélios poursuis son développement vers une meilleur compatibilité avec le monde asynchrone, l'avc1394.device me cause bien des soucis...
Je viens tout juste hier de refaire Hélios pour qu'il puisse utiliser uniquement des boites-aux-lettres, système de messages utilisés pour faire des IPC.
Avec ça je me suis dit que j'allais enfin pouvoir faire l'avc1394.device.... bah c'est plus compliqué!
Effectivement c'est mieux que l'ancienne version qui pouvait manger tous les signaux disponibles des tâches systèmes. Mais cela ne résout en rien le pb du protocol AV/C...
Pour faire simple pour demander par exemple à votre caméra à quelle image
elle se trouve, vous devez d'abord lui envoyer une commande qui correspond à
cette demande. Ceci se traduit en 1394 par une transaction
complète. Et là vous n'avez pas encore votre réponse et c'est
là mon souci: la transaction est du type écriture, donc la réponse à celle-ci
n'est qu'une sorte d'acquittement. Si cette écriture doit provoquer l'envoi
d'un résultat, ces données viendront par une toute autre façon:
La caméra viendra elle-même répondre en envoyant un paquet 1394 d'écriture
aussi, contenant le-dit résultat, à une adresse CSR définie par le standard
AV/C ($fffff0000D00 pour être précis... oui c'est sur 48bits les adresses
1394!).
Donc il va falloir dire à Hélios que si un nœud (la caméra ici) veut nous dire quelque chose à cette adresse, c'est que c'est une réponse à une requête faite précédemment par une application.
Le problème c'est que le paquet de réponse de la caméra n'est en rien lié avec une requête, en gros impossible de savoir qui a demandé se résultat jsute en regardant le paquet entrant...!
Ceci implique donc quelque chose d'important: si une application souhaite communiquer avec un noeud supportant l'AV/C, cette communication doit être unique dans l'espace et dans le temps, c.-à-d. que:
- aucunes autres applications ne peut venir demander des infos si l'application courante attend une réponse.
- une application donnée ne peut demander quelque chose, si et seulement si elle n'est pas en attente d'une réponse.
Finalement tout cela pour dire que faire un avc1394.device n'a aucune utilité et que je peux faire une simple bibliothèque fonctionnant en synchrone uniquement (à cause point 2).
Commentaires
Yop yomgui,
Pour le AV.device, c'est le même soucis que pour le serial/parallel.device. Une seule application peut utiliser le device a un instant donné et la contrainte temporelle est identique il me semble.
Ou alors, j'ai pas bien compris.
A ce sujet, rien n'interdit de faire des requêtes asynchrones... du moment que les messages en retour sont distribués dans l'ordre des émissions.
Ca serait bien dommage de se priver du couple SendIO et DoIo quand même... Le device peut conserver l'état des requêtes émises et en attentes de réponse et fonctionner en mode exclusif (une seule application par périphérique!)
Enfin bong, c'est toi qui voit, tu es sûrement plus au fait que moi.
Czk