Version imprimable
Bonjour à tous ! :)
Aujourd'hui (et depuis une semaine ... :() je suis confronté à un problème : Comment fait-t-on pour contrôler un port usb ? 8O. Je m'explique, ce que j'aimerai faire c'est allumé ou éteindre un port usb, varié sa puissance (sans dépasser 5 volt bien sûr) en ligne de commande ou dans une fenêtre et tout ça en C++ ! :D
Et donc c'est pour cela que j'ai besoin de votre aide :
Est-ce possible en C++ et si oui, comment ?
merci d'avance :)
Salut,
Je ne pense pas que tu puisse faire varier l'alim de ton port usb.
Par contre, tu peux acheter des cartes relais usb (entre 50€ pour 2/4 cannaux et 150€ pour 8 cannaux), qui sont en général fournis avec une petite lib te permettant d'activer ou non les relais.
Cherche "carte relais usb" sur google, tu devrais trouver plus d'info.
En fait, c'est — au mieux — de la programmation système. C'est-à-dire qu'il faut demander à ton O.S. de faire l'opération, qui lui-même va en intimer l'ordre au pilote. Donc, c'est indépendant du langage, si tant est qu'il existe une API dans le langage de ton choix. En principe, en C++, tu dois toujours pouvoir faire ce genre d'appel, mais celui peut ne pas être proposé par ton système.Citation:
Envoyé par Nerkem
D'autre part, les contrôleurs USB eux-mêmes varient grandement d'une implémentation à l'autre. Certains peuvent être entièrement contrôlés (extinction, etc), d'autres ne le peuvent pas et c'est parfois assez pénible. Ça dépend de ce que la norme USB elle-même impose ou non.
Enfin, il faut savoir que ces choses-là sont gérés en principe par les périphériques et le contrôleur eux-mêmes, lors de la négociation qui se produit lorsque tu branches un périph'. En fait, sous son apparente simplicité aux yeux de l'utilisateur, l'USB est une industrie très sophistiquée. Si l'on part de zéro, il est plus difficile de concevoir un périphérique 100% compatible USB qu'une carte réseau.
merci des ces réponse :).
Une petite question : vu que ça relève de la programmation système, est-ce envisageable en assembleur ?
Il y a deux réponses possibles à ta question :Citation:
Envoyé par Nerkem
— Si tu peux appeler le système depuis le C ou le C++, alors tu peux forcément l'appeler depuis l'assembleur. C'est juste un peu plus fastidieux, et cela va principalement consister à utiliser la même macro (INVOKE) servant en fait à faire un appel de fonction dans les règles. Le résultat sera le même ;
— Si tu veux piloter directement le hardware avec un code source en assembleur, c'est possible également puisqu'au final, c'est ce que fait le système et parce qu'il n'y a pas d'autre moyen, quand on arrive « en bout de chaîne », d'exploiter un ordinateur. Mais ce sera très fastidieux et cela reviendra, au bout du compte, à écrire un pilote de périphérique.
Ce dernier cas reste bien sûr extrêmement intéressant à étudier et cela se faisait beaucoup dans les années 1990 (et d'une manière générale de 1980 à 2000, toutes machines confondues, pour donner un ordre d'idée). Les deux principaux problèmes qu'il te faudra affronter seront alors :
- Le pilotage d'un port USB n'a rien à voir avec le celui d'un port parallèle ou d'un port série. Si tu pars vraiment de zéro sans utiliser l'existant, alors il te faudra écrire tout l'environnement USB avant de pouvoir commencer à dialoguer avec le ou les périphériques branchés dessus. Si tu veux juste éteindre ou allumer ton port, cela dit, ça reste envisageable ;
- Même s'il y a quelques grandes familles de fondeurs pour les puces USB (comme pour les autres), et que les grandes lignes de leur fonctionnement sont posées, chaque contrôleur sera implémenté d'une manière qui lui est propre et aura besoin d'un pilote dédié. Si tu arrives à trouver les spécifications du tien, le programme que tu auras développé pendant des mois ne fonctionnera que sur ta machine et sur celles qui sont équipées du même modèle.
Pour te donner une idée, c'est à peu près le même genre de travail que de vouloir piloter en assembleur la carte Ethernet pour causer avec le PC d'à côté : il faudra d'abord réécrire toute la gestion d'Ethernet pour ta carte réseau en particulier, puis implémenter une pile TCP/IP au dessus de tout ça, avant de commencer à envoyer des ordres à côté.
Cela dit, si ces choses t'intéressent, tu peux télécharger un système d'exploitation libre, tel que le noyau Linux et regarder les sources. Ça te donnera une bonne idée de la manière dont le tout est organisé et, en plus, tu trouveras forcément le pilote correspondant à ta machine.
Maintenant, si ton objectif n'est pas de découvrir la chose mais réellement de piloter l'alim d'un objet branché dessus (une petite lampe, par exemple), alors il faut se tourner vers l'API proposée par ton système d'exploitation.
Merci beaucoup pour cette réponse :) . Je vais essayer de trouver dans le noyau de Linux, comment fonctionne les port usb :D. Et après je verrais si je doit me penché sur l'assembleur ou le C++.
Salut,
On développe des drivers 100% en C ou 100% en C et en C++ sans ASM (100% C++, je n'ai pas souvenir d'avoir vu mais spontanément, je ne vois pas ce qui l'en empêcherait).Citation:
Envoyé par Obsidian
Je n'ai pas dit le contraire. Je répondais à sa question.Citation:
Envoyé par 3DArchi
Maintenant, il y a pilote et pilote : contrôler une imprimante, par exemple, c'est purement protocolaire. Ça peut être fait par une application en user-space dans n'importe quel langage. Piloter une carte graphique 3D, par contre, ça va demander de savoir gérer un GPU, et d'utiliser un bon nombre de registres propres à la carte. Quand on pilote du matériel, on arrive quand même au bout d'un moment à faire des mouvements sur les ports I/O, fussent ces mouvements être effectuées via des fonctions inline plutôt que d'authentiques appels en assembleur.
Par ma phrase, j'entendais par là que tout programme finit toujours par être converti au final en langage machine et qu'il est donc forcément possible, en théorie, de tout faire en assembleur. Maintenant, la quantité de travail que cela impliquerait, c'est un autre problème.
question: quel intérêt ?Citation:
Envoyé par Nerkem
Si tu penses que ça va être plus rapide, détrompe toi : la grande majorité de ton temps, tu va attendre que la commande envoyée se termine.
Si tu penses que c'est le seul moyen à cause des limitation du système : si tu peux le faire en asm, alors tu peux le faire en C (et donc en C++). La seule différence, c'est le contrôle de la pile que tu n'as pas à faire en C (ou en C++). Pour le reste, il y a peu de chance que tu génère du code ASM que tu ne pourrais pas traduire en C.
Si tu veux réduire la taille de ton code, ça peux s'envisager - notamment si tu es sur une plateforme embarquée. Si tu travailles sur un PC, la question ne se pose même pas : à quoi bon créer un programme de 50 octets ? l'OS n'est pas optimisé pour gérer des programmes de cette taille.
La règle est la suivante :
* si tu es en user space, tu programmes dans un langage haut niveau (C, C++, voire encore plus haut niveau : C#, Java, ...)
* si tu es en kernel space, tu programmes dans un langage de haut niveau (C, C with classes ; C++ impose trop de choses, mais il est tout à fait possible d'enlever d'un programme C++ les problématiques liées aux exceptions, au RTTI, etc, de manière à générer du code exécutable par un kernel ; Numega vends depuis des années un framework C++ permettant de faire des drivers sous Windows).
* si tu es dans la phase de boot d'un kernel, il est possible que tu ais l'obligation de faire un petit peu d'asm ; mais c'est vraiment exceptionnel.
J'ai envie de dire que, même si ce n'était probablement pas l'idée première du PO, c'est toujours une bonne idée de se donner un bon prétexte de le faire.Citation:
Envoyé par Emmanuel Deloget
Aujourd'hui, je développe principalement en C et C++, il m'a fallu un tout petit de temps pour admettre qu'il est vraiment très difficile de prendre un compilateur moderne en défaut (au niveau de l'optimisation du code, je veux dire) et ça m'amène tout naturellement, comme les autres, à orienter les débutants vers la voie la plus adaptée.
Cela dit, je suis quand même heureux d'avoir fait beaucoup d'assembleur quand c'était à la mode et d'avoir fait un maximum de programmes en BASIC avec des goto dans tous les sens (utiles avec 64Ko de RAM pour le système entier).
Priver les débutants de cela aujourd'hui, c'est les maintenir volontairement dans un concept abstrait. C'est un peu comme apprendre les procédures d'un avion de ligne sans jamais avoir volé sur un avion de tourisme. Non seulement ce n'est pas souhaitable, mais la règlementation ATPL impose carrément un minimum de 1500 heures de vol à ceux qui y prétendent.