DSPiy v1 sur pc avec port USB3

[alka]

avec toutes ces manips, maintenant la carte arduino avec CP2102 n'est plus reconnue par le thinkpad T460 alors que ça marchait très bien avant
Dans ce cas, le port com virtuel a l'air créé mais pas de numéro de port assigné. Bien sur, les logiciels ne le trouvent pas.
Et quand je tente de forcer un numéro de port com, windows plante. C'est un cauchemar cette affaire...

Reste que le ch340g qui lui marche toujours. ah les chinois, bientôt restera plus qu'eux !

[thierryvalk]

ah les chinois, bientôt restera plus qu'eux !

Et ton Thinkpad, il est de quelle nationalité ?

[alka]

j'ai rien contre les étrangers

je pense que c'est l'affectation des ports com virtuels dans windows qui ne va plus sur ce thinkpad.
Windows a sa manière d'attribuer les numéros de port com virtuels :
-D'un coté il garde une liste des devices qui se sont connectés pour que le device reçoive le même numéro de port com a la prochaine connexion. Il les identifie par Vendor ID, Product ID et Serial Number. Si pas de serial number, il en créé un*.
-De l'autre, une clé de registre** contient les numéros port COM déjà pris. Un nouveau device aura le numéro libre suivant. Ce qui au fur et a mesur de la connexion de différents devices sur un pc donne des numéros de port de plus en plus grand.
-Les ports com 1 et 2 ne sont jamais attribués car réservés aux ports physiques sur la carte mère.

Ce mécanisme a l'air cassé sur mon thinkpad. J'ai trouvé la clé de registre car c'est la meme depuis win7. Pas encore trouvé l'endroit où sont stockés les correspondances qu'il se réserve. Pour win7 c'était dans le registre. Manifestement en regardant mon pc HP, ca a changé dans w10 et google n'aide pas.
J'aimerai purger tout ça pour repartir d'une base propre sur le thinkpad et pour l'instant, suivre les méthodes trouvées ne l'a pas permis.

(*)http://stackoverflow.com/questions/26754128/how-does-windows-map-the-virtual-com-port-to-a-device
(**)clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\COM Name Arbiter\ComD
explications http://superuser.com/questions/408976/h ... rts-in-use

[thierryvalk]

Il est possible de modifier le driver FTDI pour que justement il ne tienne pas compte du numéro de série et assigne toujours le même port.
C'est ce que j'avais fait sur mon PC vu qu'utilisé pour tester les commandes groupées.

Ce que je sais, c'est qu'en port virtuel, c'est l'horreur en Bluetooth vu que là Windows (7 en tous cas) garde l'assignation du port disponible, même si le device n'est pas branché.
Nettoyage manuel de la base de registre nécessaire.

[alka]

Ce que je sais, c'est qu'en port virtuel, c'est l'horreur en Bluetooth vu que là Windows (7 en tous cas) garde l'assignation du port disponible, même si le device n'est pas branché.
Nettoyage manuel de la base de registre nécessaire.

oui et pas qu'en bluetooth ! c'est pareil avec w10.
La manière de le faire a changé mais le principe que je décris au post précédent reste et c'est un peu plus facile de nettoyer avec w10.

J'ai laissé tomber le driver FTDI et me focalise sur le CP2102 qui m'ennuie bien plus. Manifestement le mécanisme de windows d'affectation des ports com de mon thinkpad est corrompu et je ne trouve rien pour le réparer...

[alka]

au fait, où DStudio trouve t il la liste des ports com ouverts ?

[thierryvalk]

Par la fonction SerialPort.GetPortNames();

[alka]

fonction qui consulte la clé de registre HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM

merci. je localise de mieux en mieux le probleme sans trouver comment le réparer.

Une étape m'échappe encore.
Quand je branche un device qui focntionne : ding dong, le device est reconnu et installé (apparait dans ENUM), le port com virtuel est créé et une entrée apparait dans la clé de registre SERIALCOMM.
C'est bien toujours le meme numéro de port com qui est assigné, ou que je branche le device, ce qui est normal.
Pour le CH340G c'est COM8. Il associe VID, PID et serial de ce device à COM8. Je n'arrive pas a trouver où windows garde en mémoire que c'est 8.

Normalement, dans les propriétés bouton avancé, on peut changer le numéro de port com d'un device. Mais windows plante quand j'essaie.

Sur les devices qui ne marchent plus (dspiy ou cp2102) il reconnait et installe le device qui apparait sans erreur visible mais en réalité ça ne va pas au bout. Pas d'entrée dans la clé SERIALCOMM. C'est que le port com n'est pas vraiment créé.


Mon windows semble s’emmêler dans la création des ports coms virtuels. Sais pas trop pourquoi. Sans doute quelquechose d'incohérent quelque part.
J'intuite que si j'arrive purger la liste de correspondance entre device (VID, PID serial) avec numéro de COM, ca le remettra en meileure forme. Mais je ne trouve pas où il conserve ces correspondances. C'est sans doute dans le registre, quelque part...

[thierryvalk]

peut être :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FTDIBUS

et/ou
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FTSER2K

[alka]

non c'est pas là. C'est une mécanique windows donc sans doute dans un endroit a lui qui ne dépend pas du fournisseur. En tout cas, c'est bien planqué !

J'ai résolu mon problème en réinstallant un backup système du Thinkpad T460 qui date d'avant l'installation de ces drivers port série.

Après restauration, les clés concernées du registre étaient vierges.

Puis j'ai branché successivement les devices en laissant windows 10 trouver tout seul le driver.
- pour le CH340G : OK. W10 a trouvé le dernier driver 3.4.2014.8, l'a installé et cette carte est maintenant associée à COM3. C'est le premier numéro disponible puisque COM1 et 2 sont réservés à la carte mère.

- pour le CP2102 : OK aussi. Elle a le port COM4. Curieusement w10 n'a pas récupéré le dernier driver Silabs mais un vieux 6.7.0 datant du 19.3.2014 , donc antérieur à la sortie de W10. Auparavant j'avais installé manuellement le dernier disponible 6.7.4.261 de décembre 2016. Comme ça marche, je n'ai surtout pas essayé de changer de driver !

- pour le DSPiy v1, FTDI 230X , w10 a trouvé et installé le dernier driver en date (2.12.24.0 du 18.9.2016) et ça marche pas. Erreur Code 10 comme auparavant. En passant par le hub USB, erreur 43 jusqu'à trouver le bon cable et là c'est bon: windows le voit et lui a donné le port COM5. Mais.... DStudio n'arrive pas a se connecter
Je reviens à la suspicion des résistances séries. On verra la suite quand je les aurai changées.

Je refais un backup système

[alka]

je regarde pour remplacer R49 et R50



ce sont bien elles marquées 4R70
j'ai trouvé des 33ohm... 0805 c'est tout petit... deux chances de faire plus de mal que de bien...

[alka]

auto-réponse: me suis lancé comme un grand.
Une petite frayeur a la soudure d'une des résistance qui a fait ... de la résistance !

maintenant ça marche : DSPiy v1 reconnu de suite sur le Thinkpad T460 et reconnu par DStudio

[thierryvalk]

0805, c'est encore grand.
Comme quoi il suffisait de la faire.

Je précise que ces 2 résistances de 4R7 ne sont que sur les protos, mais que même avec des valeurs correctes cet USB reste "susceptible".

[alka]

tu m'étonnes que les chinois fassent travailler les enfants : il faut des petits doigts avec des composants aussi petits ! ou alors un robot. au choix

Ce qui est étonnant c'est que je n'ai jamais eu de soucis avec ce proto jusqu'à maintenant. Il a été branché sur 3 pcs auparavant sans souci et c'est le 4ème qui l'a perturbé. Terriblement perturbé avec le bazar que ça a mis dans le registre... bizarre ce qui s'est passé.

La leçon que je tire aussi de tout ça c'est qu'il faut laisser faire windows 10 pour installer les drivers.