utilisation ReadPipe et WritePipe sous USB/HID
Michael31
Membre
Bonjour,
Le projet décrit dans un sujet précédent avance, le GUI est fonctionnel.
La communication HID est établie avec le MCU externe ( le code est essentiellement en C ) mais je tombe sur un problème avec les API dédiées au mode HID : la notion de pipe n'existe pas (sauf erreur de ma part, mais j'ai lu pas mal de notes sur le web à ce sujet ) , seuls les "éléments" existants sont accessibles. Conséquence :je ne peux envoyer/recevoir correctement les octets utilisés pour le fonctionnement du système. Pour information, l' électronique externe fonctionne sans défaillance avec un ordinateur "autre" (désolé ...). Toujours selon le web, la solution consiste à passer par les routines définies pour le support USB. Les exemples fournis par Apple sont intéressants , un poil trop lourds pour mon utilisation.
Avez vous une expérience dans ce domaine ? Dois-je re-écrire tout le code en oubliant les API pour rester au niveau USB
?
bye
Michael
Le projet décrit dans un sujet précédent avance, le GUI est fonctionnel.
La communication HID est établie avec le MCU externe ( le code est essentiellement en C ) mais je tombe sur un problème avec les API dédiées au mode HID : la notion de pipe n'existe pas (sauf erreur de ma part, mais j'ai lu pas mal de notes sur le web à ce sujet ) , seuls les "éléments" existants sont accessibles. Conséquence :je ne peux envoyer/recevoir correctement les octets utilisés pour le fonctionnement du système. Pour information, l' électronique externe fonctionne sans défaillance avec un ordinateur "autre" (désolé ...). Toujours selon le web, la solution consiste à passer par les routines définies pour le support USB. Les exemples fournis par Apple sont intéressants , un poil trop lourds pour mon utilisation.
Avez vous une expérience dans ce domaine ? Dois-je re-écrire tout le code en oubliant les API pour rester au niveau USB
?bye
Michael
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pour ma par, j'utilise un frameworks privé pour gérer les connexions USB (je ne peux pas le diffuser désolé). Je trouve que depuis 10.5 la gestion des périphérique HID est plus compliqué. Selon mon périphérique USB j'utilise aussi le CDC qui est une émulation d'un port série permettant un dialogue simple.
Dès que j'ai besoin de gros débit j'utilise des connexions Bulk !
L'USB est un vaste sujet et il faut bien l'étudier pour arriver à le maitriser. Dans le cas d'un périphérique devant tourner sur tout les systèmes je privilégie les class CDC ou HID. Car des pilote générique existe dans la plus part des cas. Auquel cas c'est l'application qui gère le matériel qui intègre le pilote.
En espérant t'avoir aider et ne m'être pas trop répété avec ce que j'ai surement du dire dans l'autre sujet !
a+
Merci pour les commentaires.
A ce jour, le système fonctionne sous HID : je peux donc envoyer les commandes et les données au périphérique, au format bulk sur deux End Points pour établir les communications. Le code ainsi créé est dédié à l'électronique externe. J'ai passé pas mal de temps pour éplucher la documentation Apple qui est un tantinet "touffue". En effet, comment disséquer le bon grain de l'ivraie dans les centaines de fonctions qui gèrent les fonctions HID associées au port USB.
Beaucoup de temps aussi, pour un non spécialiste objective-C et/ou Cocoa, pour extraire les bytes binaires pour envoyer les codes hexadécimaux (saisis par l'utilisateur via le GUI ) au périphérique.
Une autre difficulté : comment activer la fonction LOGGER de l'outil USB prober inclue dans le Mac ? Encore une fois, pas de documentations ni d'aide en ligne...
Il me reste à lire les données en retour du périphérique : un problème à résoudre car la fonction IOHIDDeviceSetReport me retourne l' erreur "pipe has stalled, error must be cleared" La aussi, la documentation est pauvrette !
Je ne manquerais pas de vous tenir au courant de la suite du développement,
cordialement,
Michael
Bonne question je n'en sait absolument rien ! Je ne l'ai jamais utilisé !
La documentation sur l'USB et sont utilisation est assez pauvre car parfois il faut aller chercher dans les fondement BSD et du standard USB.
Le système avance, le dialogue avec le périphérique est fonctionnel dans les deux sens ( erreur d'écriture entraà®nait un verrouillage du pipe de lecture ).
Il reste pas mal de boulot, sans oublier le déverminage "propre"
Aujourd'hui, un nouveau problème : crash du programme lors de l'affichage en retour depuis le port USB selon l'origine de dèpart des données devant êtres envoyées sur le port USB. Curieux si l'on considère que les octets sont identiques au bit prés, aussi bien dans le sens montant que descendant. Mais je suis "nul" en cocoa & Co, donc erreur d'analyse en perspective. Reste à fouiller ....
Merci pour l'intérêt que vous portez à ce système plus électronique que logiciel !
cordialement,
Michael
J'ai pas très bien compris le problème. Lors de la l'affichage des données cela plante ? Sous quel formes sont affichées les données ? Avant de les afficher sont elles vérifiées (CRC) pour éviter d'utiliser des données corrompues ?
J'ai toujours aimer l'électronique. Même si je ne suis pas électronicien mais développeur j'apprécie toujours un montage qui communique avec l'ordinateur de façon correct et fiable (encore plus si c'est un mac). Avec l'USB cela a compliqué la tâche mais cela est faisable.
Le crash était du à une erreur de dimension du tableau contenant les quatre bytes: tout fonctionne comme attendu dans les deux sens:
// cette ligne introduit une erreur , on attend huits caractéres hexadecimaux
uint8_t inputReportHID[255];
// fonctionnement correct avec cette ligne
uint8_t inputReportHID[8];
CFIndex reportSize = sizeof(inputReportHID);
L'affichage dans la fenêtre dédiée au retour du port USB fonctionne, ainsi que la sauvegarde et l'impression de son contenu. De même, la lecture et l'affichage d'un fichier précédemment enregistré.
Le périphérique fonctionne sans problème : j'ai le plaisir de faire fonctionner une électronique sous Mac et non sous le sempiternel W... Le système est donc bien "vivant" .
Lors du retour depuis le module électronique (analyse d'un bus I2C et commande des devices associés ) , je souhaite passer en rouge les lignes comportant une erreur détectées au niveau du bus I2C, les autres cas étant traités en bleu. J'arrive bien à passer un code de couleur, mais cela s'applique à toute la fenêtre et non ligne par ligne : encore un peu de recherche sur ce sujet....
Méthode employées:
// no error back from USB
[USBbusData setTextColor:[NSColor blueColor]];
[USBbusData insertText:hidBack]; // No I2C error: Display the four bytes returned from USB external device
// I2C error detected
[USBbusData setTextColor:[NSColor redColor]];
[USBbusData insertText:hidBack ];
avec = IBOutlet id USBbusData;
Une idée ???
Ensuite, il me reste à écrire le manuel , avec une tentative pour le mettre en ligne avec le programme, ainsi que les schémas de base si cela est possible ...
Coté électronique, on peut toujours partager des idées ... ou des problèmes à résoudre ....
Cordialement
Michael
Affiche en rouge la chaà®ne str:
Un grand merci : l'affichage est impeccable
Bon dimanche
cordialement,
Michael