DMX Controller, besoin d'aide
orfait
Membre
Bonjour,
Je recycle ce topic car le projet est tombé à l'eau suite à des besoins biens plus précis.
La nouvelle application n'est pas vraiment totalement différente dans le fond, mais dans la forme, on a du changement.
Le but premier : envoyer sur un périphérique USB des informations par blocs de 64 octets (5 blocs au total). Et ceci avec une fréquence de rafraà®chissement de 50Hz environ (sauf si le bloc en question est inchangé).
Le premier problème : si je met du timer avec une période de 20ms, l'interface graphique se bloque et le soft devient inutilisable (par exemple, certaines valeurs sont modifiés par des sliders... et c'est vraiment saccadé/bloqué).
Le second problème : le périphérique USB respecte la norme HID, mais je lui ai fait un driver pour qu'il soit "pris" par IOUSBInterface. L'ennui, c'est que je dois me reconnecter au périphérique à chaque fois, soit au pire 250 fois par seconde. C'est tellement consommateur de ressources que j'avais même envisagé me rabattre sur un port série...
Le second but : recevoir les données qu'envoie le périphérique USB... toujours 5 blocs de 64 octets à 50Hz (si les blocs sont modifiés).
Pour reconnaà®tre chaque bloc, on utilise un des octets (le premier par exemple).
J'ai quelques connaissances en programmation en Objective-C. J'utilise XCode3 et mon soft peut être spécifique à léopard.
Et finalement, ce que je demande, c'est quelle tournure doit prendre le projet... comment faire pour parvenir à mon but sans que le soft soit une usine à gaz ni que la machine soit trop ralentie...
Je vous remercie d'avance pour vos conseils.
Je recycle ce topic car le projet est tombé à l'eau suite à des besoins biens plus précis.
La nouvelle application n'est pas vraiment totalement différente dans le fond, mais dans la forme, on a du changement.
Le but premier : envoyer sur un périphérique USB des informations par blocs de 64 octets (5 blocs au total). Et ceci avec une fréquence de rafraà®chissement de 50Hz environ (sauf si le bloc en question est inchangé).
Le premier problème : si je met du timer avec une période de 20ms, l'interface graphique se bloque et le soft devient inutilisable (par exemple, certaines valeurs sont modifiés par des sliders... et c'est vraiment saccadé/bloqué).
Le second problème : le périphérique USB respecte la norme HID, mais je lui ai fait un driver pour qu'il soit "pris" par IOUSBInterface. L'ennui, c'est que je dois me reconnecter au périphérique à chaque fois, soit au pire 250 fois par seconde. C'est tellement consommateur de ressources que j'avais même envisagé me rabattre sur un port série...
Le second but : recevoir les données qu'envoie le périphérique USB... toujours 5 blocs de 64 octets à 50Hz (si les blocs sont modifiés).
Pour reconnaà®tre chaque bloc, on utilise un des octets (le premier par exemple).
J'ai quelques connaissances en programmation en Objective-C. J'utilise XCode3 et mon soft peut être spécifique à léopard.
Et finalement, ce que je demande, c'est quelle tournure doit prendre le projet... comment faire pour parvenir à mon but sans que le soft soit une usine à gaz ni que la machine soit trop ralentie...
Je vous remercie d'avance pour vos conseils.
Bonjour,
je viens ici pour faire quelques tests de mon application "PowerBox Controller", toujours en développement ceci dit...
Ce logiciel est prévu pour contrôler deux interfaces USB ("PowerBox II" et "PowerBox II RE") et afficher des animations sur un écran secondaire, tout ceci en fonction du son qui entre au choix dans l'entrée ligne ou via le micro intégré (pour choisir l'entrée voulue, il suffit normalement de la sélectionner dans les préférences système).
Plus d'info sur les interfaces sur http://www.orfony.fr
Je suis aussi preneur de toute suggestion.
Les fichiers : http://sourceforge.net/projects/pbc/ (les sources sont disponibles via svn).
Merci aux cinglés qui testeront ::)
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ben, c'est trop vague comme description...
Que demandes tu au juste ?
Envoyer/Recevoir via USB depuis un prog Cocoa ?
Manipuler ce que tu envois/émets ?
Bonne idée.
Et d'ailleurs, si tu pouvais y rester...
.
Non, j'avais déjà demandé pour l'envoi par USB et j'avais été bien aidé et guidé (merci Mala d'ailleurs).
Ce que je demande surtout, c'est quel serait le type de structure de programme permettant d'éviter le "gel" de l'interface graphique. Je me souviens avoir essayé de lancer un timer qui faisait l'envoi USB toutes les 20ms via un bouton simple, et ceci avait pour effet de faire totalement laguer l'interface graphique.
Je cherche donc la voie à suivre pour tenter d'optimiser au mieux le transfert... Par exemple la structure qui vous semblerait la plus optimisée...
Je ne connais pas ce forum, donc impossible de savoir si c'est un conseil ou une blague... Je veux bien une éclaircissement.
Mais je suis étonné du "dégage et ne reviens pas" de la part de quelqu'un qui chercher à éviter les prises de têtes sur le forum...
Suis-je néfaste à ce point à la bonne entente ?
Ma dernière phrase répondait à un post de psychoh13.
Donc, le message ne s'adressait qu'à lui, et non à toi.
.
Lance un thread qui gère l'envoi en boucle en faisant "usleep(20000);" entre deux passages dans la boucle.
ça ira mieux pour l'interface graphique
Schlum : Merci, ça correspond à ce que j'avais commencé à coder. Donc c'est ce qui serait le "mieux".
J'ai un autre problème qui vient juste derrière, mais je vais attendre d'être sur mon mac de dev pour mettre du code ici.
Oui, je pense... Maintenant j'émets des réserves parce que je n'ai jamais travaillé avec IOKit et je ne sais pas s'il gère bien le multi-threading.
Je m'en mèle, espérant ne pas donner un mauvaise piste :
Si le Thread principal est réservé à l'interface, et un thread au traitement avec IOKit, celui-ci ne se trouve donc pas en multi-thread ?
Et si c'est le cas et que ça bloque, il y a les techniques Unix habituelles : une application en ligne de commande, une interface pour commander, et un mécanisme de sémaphore/mémoire partagée pour les faire communiquer. (ça complique, sans doute à éviter )
ça me fais penser que j'ai une interface Sunlite 2002 et que j'ai pas regardé si une application savait la gérer... Si c'est pas le cas et bien c'est un projet intéressant ma fois...
Donc sauf si ton interface a le même protocole, il faudrait recoder la communication.
Mais ca ne te coûtera rien d'essayer !
Si tu parle de pbc (ex PowerBox Controller), sache que ce soft a été abandonné en totalité et que la dernière version ne fonctionnait pas.