Cartes USB Open-cockpit non reconnues

[FiX]

J'aimerais vraiment vous aider là dedans, mais malheureusement, ça dépassé complètement mes compétances!!
En tout cas je suis content de voir qu'il ya de la recherche dans le domaine... Parce que si ces maudites cartes étaient fiables, elles seraient vraiment pas mal.

[GAILLARD]

Bonjour à tous

Je viens pour vous donner peut être une idée ..;

Comment fonctionne vis à vis du PC votre connection par une prise USB ?

Souvent ces cartes fonctionnent par une connection de type USB (physique) mais sont emulées en RS232 sur un port serie de type com3 par expl

Pour le voir il faut aller dans le fichier :
- panneau de config
- systéme
- materiel connecté et regarder sur le lien USB s'il y a une ligne qui indique le transfert USB vers RS232
et sur les ports voir si la connection existe en COM3 par expl

Il est aussi impératif d'avoir une alimentation séparée pour le HUB (appel de courant de la carte qui ne peut souvent pas être supportée par la liaison au démarrage)
et également toujours utiliser la meme broche USB sur le PC pour cette fonction car elle correspond à l'ouverture d'un port et donc de l'indentification de la passerelle USB... RS232...

C'est une piste

GG

[pierre01]

BOB,

Et pour Pierre, penses tu que des problèmes de masse ou de retours de courant pourrai perturber le
contrôleur USB ou la carte mère et provoquer ces déconnections/non-reconnaissance ?
Est-il imaginable de mettre à la masse les cartes et l'alim du PC ?

Normalement toutes les masses sont reliées entres elles, mais je n'ai jamais vérifié si la masse alim PC et masse USb sont reliées, je pense que oui. Donc ça ne devrait pas changer grand chose.
J'ai moi aussi une tension sur les cartes OC quand le PC est éteint, je n'ai pas vérifié combien, mais les LED restent allumées.
C'est peut-être normal sachant qu'il y a, je crois, une option dans le BIOS permettant de laisser les prises USB alimentées, je n'ai pas non plus regardé !
Je ne pense pas que ce soit un Pb hard, c'est toujours les 2 mêmes cartes (PIC) qui ne sont pas reconnues de temps en temps ...
Ces cartes (USBServos) sont sur un HUB auto alimenté et toujours branché sur la même prise USB.
Et pas facile d'analyser ce qui se passe quand le Pb arrive au bout de plusieurs semaines, voir mois !!!
Et que ça remarche sans savoir pourquoi ...
J'aurais donc tendance à croire que ce n'est pas non plus un Pb de driver ... mais je n'y connaît rien !

GG,

- materiel connecté et regarder sur le lien USB s'il y a une ligne qui indique le transfert USB vers RS232
et sur les ports voir si la connection existe en COM3 par expl

Je ne trouve pas cette option, mais je suis sous XP Pro sp3 avec les dernières mises à jour windows!!!

[GAILLARD]

Salut

Sous W7 , je penserai plutôt à un pb de protection de windows 7 (qui est une vrai M.... pour ça) pas vraiment libre de faire ce que l'on souhaite sans prise de tête

attention a moyen terme de désactiver aussi les mises a jour de windows qui modifient la machine mais sans savoir en quoi et rebolotte des nouvelles protections qui bloquent ce qui n'a pas de "ticket" agréer par microsoft windows

vos symptômes ressemblent bien a ce type de pb. creusez sur ces points là
Je ne pense pas a une panne des cartes, ni à des pb de liaison, c'est plutôt un pb soft et protections windows

On est toujours dans un cercle complexe , car d'un côté on vol en réseau, donc il faut avoir des protections et des mises à jour et d'un autre côté les mises à jours windows posent toujours des pb nouveaux... c'est souvent la base de tous les pb

[A320 hérétique]

Bonjour,

Oui, attention aux mises à jour automatiques de Microsoft, elles peuvent tout déstabiliser, ça m'est arrivé il y a qques semaines à l'occasion d'une démo qui a complètement foiré alors que le matin même tout était OK, j'ai rapidement vu qu'entre temps 2 màj étaient intervenues, je suis reparti du dernier point de resaturation juste avant et OK ... mais je ne pense pas que ce soit l'explication concernant notre pb de reconnaissance, car les périp USB OC sont des périph de classe très standard (HID - Human interface device), et relèvent du même driver de base que clavier, souris, ... hors nous ne rencontrons pas de pb avec ces derniers.

Attention, dans nos réflexions, car nous faisons l'hypothèse que tous nos pb USB OC n'ont qu'une explication, alors qu'ils sont quand même assez variés, donc prudence ; cela étant, notre hypothèse me semble qd même vraisemblable.

J'ai poursuivi mes investigations, et vous raporte qque-chose d'intéressant ; mais d'abord, je vous rapelle mon contexte, et vous présente un petit résumé simple de comment ça marche :
1) Contexte : sur l'un de mes PC, OK sur les ports USB 3 (alors que les cartes OC sont USB 1.1, basse vitesse) ; en revanche KO sur les ports USB 2 (device inconnu, et même blocage au démarrage du bios sans pouvoir rentrer dans celui-ci) ; les ports USB 3 sont dotés d'un controleur NEC, avec un driver bios spécifique , les autres sont directement pilotés par le chipset.
2) Comment ça marche (je suppose que comme moi vous n'y connaissez pas grand-chose ! alors j'ai un peu fouillé ...)
- au démarrage, le bios tente de reconnaitre les périph ; pour les ports USB, il détecte sur les 2 fils de données une tension basse qui dit qu'un périph est connecté ; il envoie pendant 10 ms un signal d'initialisation au périph et lui fournit du courant ; le périph commence à fonctionner avec l'adresse par défaut 0 ;
- dans un second temps, le PC procède à l'énumération (reconnaissance de tous les autres périph USB), de façon à pouvoir leur attribuer et leur communiquer une adresse définitive.
- le périph renvoie alors au bios ses caractéristiques complètes, qui vont permettre au bios de mettre en oeuvre un driver de base.
- à ce moment là, dans le bios on peut voir que le périph a été reconnu.
- windows se charge, et va également procéder à la reconnaissance de tous ces périph, et charge en conséquence soit un driver standard, soit un driver plus spécifique ; quand on branche à chaud un périph, le couple bios (qui doit être plug-and-play), et windows (qui doit également l'être également) redéroule tout le processus.

Bon, je ne pense avoir dit trop de bétise ; à partir de là, je me lance, que peut-on en déduire ?
- si, périph branché, le bios ne démarre pas, mais qu'il démarre dès qu'on débranche le périph (c'est mon cas), ça veut dire que le bios a bien vu un périph (la tension basse entre les 2 fils de données), mais qu'il n'arrive pas à conclure l'énumération (et donc ça bloque tout) ; on n'est pas encore arrivé à la sélection d'un driver bios de base, le problème est vraimement un problème de très bas niveau, car on sait par ailleurs que le périph sait fonctionner et fournir toutes ses caratéristiques.
- si branchement à chaud du périph, et erreur device inconnu, même explication, mais on ne bloque pas tout, car les autres devices USB ont déjà leur adresse.

J'aurai tendance à conclure à une implémentation hard un peu limite qui ferait que le couple controleur USB coté PC et PIC coté carte OC n'est pas fiable.

Mais ce matin j'ai fait un essais qui ne va pas vraiment dans ce sens : j'ai lancé une session UNIX live (un Mandriva 2008.1) : pour ce faire, je n'ai donc pas pu laisser la carte OC (une USBaxe) connectée, car j'aurais bloqué le bios.
Dans cette conf, le bios ne peut plus faire fonctionner ses ports usb 3, puisque j'ai installé les drivers bios correspondants sous windows. Je n'ai plus donc que des ports USB 2. Je branche la carte USB de OC, et je la vois instantanément apparaitre dans les propriétés système !!
J'ai fait plein d'essais, retour sous windows, puis sous unix, comportement systématique.

Là, on pense quand même plus à un pb soft !

J'en mange mon chapeau !!

Cordialement
Michel

[stevelep]

Tu veux dire que sur le même PC et le même port USB sous Seven la carte est pas reconnue et sous Linux
elle est reconnue tout de suite ?

Ça veux dire que c'est pas un problème de carte mais de driver W7 ?

Bravo pour ta persévérance qui va assurément apporter beaucoup à la communauté.
Je t'aiderais si je pouvais mais j'ai pas de problème chez moi sur plusieurs Pc avec xp ou W7
je ne peux pas reproduire la situation ....

Merci de continuer tes investigations, on va bien finir par trouver la solution

BOB

[A320 hérétique]

Oui, c'est ça Bob, mais le hic, c'est que ce même driver sur un autre PC avec la même carte OC, c'est OK !!! (en fait, c'est un driver hyper standard, utilisé par windows pour tous les périph HID, et dieu sait s'il y en a, et qui fonctionnent ...).
Cordialement, Michel

[FiX]

J'ai pu tester 2 nouveaux PC avec les cartes lcd:
-un en XP=> ma carte non reconnue et celle de BOB reconnue
-un en vista => les 2 cartes sont reconnues.

Donc en résumé, ce que j'ai pu tester depuis le début:

3 vista: 100% OK avec les 2 cartes
4 XP: 2 cartes OK sur un PC et une seule carte sur un autre PC. Le reste KO
2 seven: 100% KO avec les 2 cartes

[pierre01]

Fix,
Que se passe t-il si tu inverses 2 PIC (sur deux cartes de même type bien sûr) ?

Michel,
Que veux tu dire par

J'aurai tendance à conclure à une implémentation hard un peu limite qui ferait que le couple controleur USB coté PC et PIC coté carte OC n'est pas fiable.

?
Veux tu dire que les CI (PIC et Chipset) ne sont pas PHYSIQUEMENT compatibles ou es-ce au niveau programmation du PIC ?

[A320 hérétique]

Pierre, en toutes modestie :

Je suis presque persuadé que le pb intervient lors de l'énumération (ce qui explique le blocage au moment du boot), voir même avant, juste après la détection (en effet, dès détection le controleur envoie un signal d'init et alimente le device, la led sur la carte devrait s'alluler, non ? - mais comment alors expliquer que cà marche avec Linux mais pas W7 avec même PC, même port et même dispo ?)

- le controleur détecte la présence du dispo, alimente la ligne et envoie son signal d'init, puis entame l'énumération (si démarrage périphe branché, c'est le BIOS et le contrôleur USB qui font ça, si branchement à chaud c'est le driver USB de l'OS et le contrôleur).
- à son niveau, le PIC offre en gros 3 services : INIT, GET et PUT ; il faut donc lancer l"INIT dès que le PIC est alimenté (l'INIT va couvrir toute la phase d'initialisation, y compris l'énumération), attendre que l'énumération soit terminée, puis on peut commencer à échanger des données à coup de GET et PUT.
A ce stade; il peut y avoir maladresse de programmation : si on n'attend pas la fin de l'énumération, il peut y avoir des erreurs, des débordements de pile, pb d'interruption, etc ; mais le fabricant du PIC fournit la macro qui va bien ..

Au niveau matériel, pas moyen de se tromper, il faut juste ajouter une résistance et une capa, peu de risque qu'il y ait pb de ce coté.

Donc oui, peut-être un problème de code de très bas niveau sur le PIC : soit OC n'attend pas la fin de l'énumération, soit gestion insuffisante des erreurs (ça pourrait même être au niveau du code propre au PIC, n'oublions pas qu'il a plus de 12 ans d'age) ; on pourrait par exemple imaginer que, selon le PC et son bios ou ses drivers, le processus d'énumération se déroule trop vite pour le PIC ; sa pile ne comporte que 8 niveaux, l'énumération en utilise 4, si par la dessus des erreurs de synchro se présentent il peut y avoir débordement ..

Pour essayer de valider ça (une influence néfaste de la vitesse sur le PC) , je pense à donwnclocker le PC qui présente le pb, penses-tu que ce soit faisable ?

Cordialement
Michel