Forum Linux.noyau driver USB

Posté par  .
Étiquettes : aucune
0
10
oct.
2005
Bonjour à tous,

Je suis en train de développer un driver USB linux, mais j'ai un probleme avec le changement d'alternate setting. En fait, je réussis à changer d'alternate setting dans la fonction probe et open mais pas dans d'autres fonctions, telles que write par exemple.

Merci pour vos réponses.

  • # avec autant d'information dans ton message

    Posté par  . Évalué à 2.

    je peut predire que le pb viens de la ligne 349 de ton fichier .C

    Nan plus serieusement pour avoir des réponse le mieux c'est que tu pose des questions non ? et que tu fournisse des elements technique.
    De quoi est sorti ton code ? usb-skelton ? form scratch ? du rubiny ?
    qu'est ce que tu fais dire que ca marche pas ?
    Tu ne vois pas le packet de controle sur l'analyseur usb ?
    Comment tu l'envoie d'ailleur ton control-packet ? quel fonction ?
    quel version de kernel utilise-tu ?

    • [^] # Re: avec autant d'information dans ton message

      Posté par  . Évalué à 1.

      Le code vient à la base de usb-skeleton, mais depuis il a bp évolué.

      En fait j'envoie une commande d'allumage de LED au peripherique USB mais elle ne s'allume pas quand je modifie l'alternate setting courant dans la fonction write. Sinon, si je modifie l'alternate setting dans la fonction probe ou open, aucun probleme.

      Pour envoyer la commande, j'utilise la fonction usb_fill_bulk_urb.

      Qu'est-ce que tu appelles l'analyseur USB?

      C'est un kernel 2.6.11


      J'espere avoir été un peu plus clair

      • [^] # 1 pas en avant

        Posté par  . Évalué à 1.

        si je resume la led s'allume quand le device recoit un control-packet change_setting.
        Plusieurs chose peuvent etre envisagée.
        1) Une coquille dans l'enum/core USB indiquant que l'alternate setting que tu tente d'envoyer
        - est deja celui encours
        - n'existe pas.
        - ne correspond pas en terme de nb de endpoint

        2)La fonction usb_fill_bulk_urb envoie un packet BULK au device pas un packet control pourquoi l'utilise tu pour l'envoie du control packet?
        (voir fonction usb_control_msg ou usb_fill_control_urb)
        N'obtient tu pas de cette fonction dans le champ status de ton urb une info ?

        3) Un analyseur usb est un appareil en vente dans le commerce permettant de s'intercaler entre un host/device et permettant d'observer les transactions usb. Son prix le reserve au "pro" plus qu'aux particulier.
        Tu peut voir avec certain commerciaux pour la location a la journé d'un tel equipement

        • [^] # Re: 1 pas en avant

          Posté par  . Évalué à 1.

          petite précision

          J'allume la LED par la commande BULK, c'est un octet envoyé au périphérique.
          Si elle s'allume, c'est que le changement d'alternate setting s'est bien passé.

          Après avoir exécuté la fonction usb_fill_bulk_urb, j'exécute la fonction usb_submit_urb qui ne renvoie pas d'erreur, c'est ca qui est bizarre.

          Je change d'alternate setting par la fonction set_usb_interface. Je verifie ensuite le nombre d'endpoint de l'alternate courant et il correspond bien.

          • [^] # Re: 1 pas en avant

            Posté par  . Évalué à 1.

            une idée comme ca.
            dans usb-skel le "write" est non bloquant :usb_submit_urb retourne immediatement cad avant que l'octet soit parti vers ton device.
            Si tout de suite derriere tu fais un set_usb_interface le urb en pending est-il toujours vivant ?je ne saurais le dire.
            1) au lieux de faire un fill_urb/submit urb peut tu essayer de faire un usb_ulk_msg ? et ensuite seulement (car la tu est garanti qu'au retour de usb_bulk_msg ton message a ete recu par le device ) de faire ton set_usb_interface.

            2)C'est une methode de faire comme cela mais elle n'est pas dans l'esprit de l'usb qui as prevu le control-endpoint afin de gere ce genre de request.

            • [^] # Re: 1 pas en avant

              Posté par  . Évalué à 1.

              J'ai essayé avec usb_bulk_msg. C'est comme avant, la LED s'allume pas si je change d'alternate setting.

              J'ai changé aussi le champ condition dans la structure usb_interface mais c'est pareil.

              • [^] # Re: 1 pas en avant

                Posté par  . Évalué à 1.

                de mémoire usb-skel ne declare a usb-core que la premiere interface du device usb.
                Peut etre une coquille dans le code que tu as rajouter pour declarer touts les altinf ?
                Sinon sans le code je vois pas d'autre piste. sur le 2.6.11 les pb de selection devrait ne plus exister.

                • [^] # Re: 1 pas en avant

                  Posté par  . Évalué à 1.

                  J'ai réussi à me débloquer.
                  En fait, j'ai remarqué que quand je change d'alternate setting, il faut envoyer deux commandes bulk de suite pour que ca marche. Ensuite, une suffit.
                  Donc ce que j'ai fait, c'est que des que je change d'AS, j'envoie une commande bidon au périphérique, et apres les commandes suivantes marchent nickel.

                  Merci beaucoup TheBreton pour ton aide, t'as été bien cool.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.