Discussion :

[Nerkem]

Bonjour � tous !
Aujourd'hui (et depuis une semaine ... ) je suis confront� � un probl�me : Comment fait-t-on pour contr�ler un port usb ? . 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++ !
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

[pyros]

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.

[Obsidian]

Bonjour � tous ! Aujourd'hui (et depuis une semaine ... ) je suis confront� � un probl�me : Comment fait-t-on pour contr�ler un port usb ? . 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++ !

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.

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.

[Nerkem]

merci des ces r�ponse .
Une petite question : vu que �a rel�ve de la programmation syst�me, est-ce envisageable en assembleur ?

[Obsidian]

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 :

� 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.

[Nerkem]

Merci beaucoup pour cette r�ponse . Je vais essayer de trouver dans le noyau de Linux, comment fonctionne les port usb . Et apr�s je verrais si je doit me pench� sur l'assembleur ou le C++.

[3DArchi]

Salut,

parce qu'il n'y a pas d'autre moyen, quand on arrive � en bout de cha�ne �, d'exploiter un ordinateur.

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).

[Obsidian]

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).

Je n'ai pas dit le contraire. Je r�pondais � sa question.

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.

[Emmanuel Deloget]

merci des ces r�ponse .
Une petite question : vu que �a rel�ve de la programmation syst�me, est-ce envisageable en assembleur ?

question: quel int�r�t ?

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.

[Obsidian]

question: quel int�r�t ?

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.

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.