Comment trouver le driver ou le chipset d'un périphérique USB ?

PPdM · Le 02/04/2013, à 12:55

Je vois que tu as des interlocuteurs plus compétant que je ne le suis, donc je vous laisse travailler.

tiramiseb · Le 02/04/2013, à 13:32

des interlocuteurs plus compétant que je ne le suis

Bof hein... J'ai fait un peu d'électronique pendant mes études, mais ça commence à dater.

C'est juste du bon sens : on vérifie le rôle de chacune des puces et on regarde comment sont "dessinés" les circuits.

jibe · Le 02/04/2013, à 15:19

tiramiseb a écrit :

C'est marqué dessus.
Lattice ECP2M

Quand je dis que je n'y connais strictement rien... J'ai cherché avec les 3 numéros de dessous, pourquoi donc ai-je zappé celui-ci ?

tiramiseb a écrit :

Lattice ECP2M : FPGA
- Samsung K4M56323PI-HG75 : mémoire
- Atmel MEGA324PA : micro-contrôleur
- Maxim MAX3051 : transceiver
- Philips ISP1583BS : interface USB <= a priori c'est lui qui gère les communications USB (placé d'ailleurs en face du port USB, c'est logique )

Super, merci ! C'est un des points qui me manquait, et qui m'empêchait d'avancer ! J'ai toujours été brouillé avec le marquage des puces...

tiramiseb a écrit :

Au vu du dessin des circuits, simple supposition :
- la puce Lattice est là pour gérer les entrées-sorties de ce matériel (SYS IN et SYS OUT)
- la mémoire est utilisée par cette puce
- la communication USB est gérée par la puce Samsung
- le micro-contrôleur Atmel se place entre les deux pour transmettre les données lues dans la puce Lattice au port USB

Ça semblerait logique (sauf inversion Philips <-> Samsung).

En fait, il s'agit d'un petit boitier quadruple convertisseur A/D 24 bits permettant de faire des mesures de tension 0->10v et 4->20mA et retransmettant ça via USB à une usine à gaz logicielle permettant de gérer ces mesures et les transmettre éventuellement à d'autres logiciels comme LABVIEW ou MATLAB.

Le survol du contenu du CD de cette suite logicielle me laissait supposer une forte interaction entre les différentes parties de la suite logicielle et la gestion de l'USB. Ce que tu me dis le confirmerait, et laisserait même supposer qu'une partie du boulot se fait dans le boitier.

L'électronique est bien conçue, mais hélas les choix faits pour la suite logicielle donnent des résultats déplorables, et le client faisait beaucoup mieux il y a presque 20 ans avec un matériel à base de 486 DX4 et quelques cartes PCMCIA, le tout tournant sous DOS !!! Il avait certes beaucoup moins de possibilités, mais c'était un peu la philosophie des LL : on ne fait qu'une chose, mais on la fait bien. Il récupérait un fichier de mesures qu'il pouvait traiter ou convertir à sa guise...

Le but est donc d'utiliser ce boitier pour faire l'acquisition et la mémorisation des mesures, le client ayant déjà ce qu'il faut pour les traiter derrière.

Je vais donc voir si on peut (faire en sorte de) récupérer la sortie des CAD sans traitement directement sur l'USB. Je me demande maintenant si ce boitier n'est pas un bazooka pour tuer un moustique, mais d'après le client, il est difficile dans le domaine de la mesure industrielle de trouver des CAD 24 bits, et celui-ci serait l'un des meilleurs et le seul bien adapté à son besoin.

tiramiseb a écrit :

Je pense que la meilleure approche serait d'utiliser le matériel sur un PC sous Windows et de "sniffer" les ports USB pour comprendre le protocole de communication utilisée.
De la rétro-ingénierie logicielle de base, quoi...

Oui, c'est ce que je pensais faire, mais j'espérais y arriver sous Linux. Ce ne serait pas possible, si je trouve un driver sachant causer avec l'ISP1583BS ? (mais je dis peut-être une bêtise ?)

pierguiard a écrit :

Je vois que tu as des interlocuteurs plus compétant que je ne le suis, donc je vous laisse travailler.

Ok. Merci pour ta proposition qui aurait pu m'être très utile. Effectivement, tiramiseb m'a donné pas mal d'éléments intéressants et je pense qu'il ne me reste plus qu'à étudier tout ça de près. Avec un petit peu de chance, je vais peut-être bien arriver à m'en sortir.

Je reviendrai donc un peu plus tard pour expliquer comment, ou si j'ai du mal à avancer pour poser d'autres questions idiotes (genre où trouver la référence d'une puce ). Merci à tous en attendant !

tiramiseb · Le 02/04/2013, à 15:31

inversion Philips <-> Samsung

Oui désolé

un driver sachant causer avec l'ISP1583BS ?

Bof. C'est juste une puce qui "sait parler en USB".
Derrière, je pense que les vraies instructions sont du côté du micro-contrôleur, et ce chip ne fait qu'interpréter tout ça.

Je me demande maintenant si ce boitier n'est pas un bazooka pour tuer un moustique

Je le pense également.
Il faudrait trouver un boîtier qui ne fait que le strict minimum de ce que tu veux... mais encore faut-il que ça existe, ce qui semble difficile selon les propos de ton client.

jibe · Le 02/04/2013, à 18:36

tiramiseb a écrit :

inversion Philips <-> Samsung
Oui désolé

Pas de problème : il n'y a que ceux qui ne font rien qui ne se trompent jamais !

tiramiseb a écrit :

Bof. C'est juste une puce qui "sait parler en USB".
Derrière, je pense que les vraies instructions sont du côté du micro-contrôleur, et ce chip ne fait qu'interpréter tout ça.

Bon, il faut que j'en apprenne plus sur l'USB : j'avais tendance à penser le contraire !
Pour moi, il faut un driver pour gérer le protocole lui-même, et le reste n'est que les données qui circulent.

Bien sûr, vu l'importance de l'électronique sur cette carte, il doit y avoir beaucoup de données qui circulent et sont traitées, mais ça reste des données, et il faut bien le protocole pour les transmettre.

Autrement dit : le driver ne s'occupe-t-il pas des couches basses du modèle OSI, et mon application ne devrait-elle pas s'occuper uniquement des couches hautes et se contenter de passer par le driver pour émettre/recevoir ces données ?

tiramiseb · Le 02/04/2013, à 18:41

Autrement dit : le driver ne s'occupe-t-il pas des couches basses du modèle OSI, et mon application ne devrait-elle pas s'occuper uniquement des couches hautes et se contenter de passer par le driver pour émettre/recevoir ces données ?

Ça dépend jusqu'où vont les couches basses, pour toi

Un driver HID (pour le clavier par exemple), ça gère toutes les couches : pas besoin d'application pour que le clavier communique avec le noyau.

Un driver de webcam, il va proposer des fonctions de haut niveau pour lire le flux vidéo, donc ton appli ne fait que lire le flux vidéo, ce qui est pour moi une fonction de haut niveau... Mais le driver ne fait pas que l'envoi/réception de données, il fait en sorte que ce soit facile à utiliser.

jibe · Le 02/04/2013, à 23:28

tiramiseb a écrit :

Ça dépend jusqu'où vont les couches basses, pour toi

C'est bien parce que je n'en sais trop rien que je ne l'ai pas précisé

Je dirais au moins de 1 à 5 inclues, même plutôt de 1 à 6.

tiramiseb a écrit :

Un driver de webcam, il va proposer des fonctions de haut niveau pour lire le flux vidéo, donc ton appli ne fait que lire le flux vidéo, ce qui est pour moi une fonction de haut niveau... Mais le driver ne fait pas que l'envoi/réception de données, il fait en sorte que ce soit facile à utiliser.

Donc, c'est bien ce que je pensais : l'appli s'occupe de la couche 7 (donc, celle que OSI appelle la couche application !), et le driver de toutes les autres.

Mais bon, on parle un peu dans le vide, là : il faut d'abord que je vois ce qui se passe, après on pourra analyser.

Merci pour ton aide précieuse, je reviens dès que j'ai pu analyser ce qui se passe sous W$.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 02/04/2013, à 12:55

Re : Comment trouver le driver ou le chipset d'un périphérique USB ?

#27 Le 02/04/2013, à 13:32

Re : Comment trouver le driver ou le chipset d'un périphérique USB ?

#28 Le 02/04/2013, à 15:19

Re : Comment trouver le driver ou le chipset d'un périphérique USB ?

#29 Le 02/04/2013, à 15:31

Re : Comment trouver le driver ou le chipset d'un périphérique USB ?

#30 Le 02/04/2013, à 18:36

Re : Comment trouver le driver ou le chipset d'un périphérique USB ?

#31 Le 02/04/2013, à 18:41

Re : Comment trouver le driver ou le chipset d'un périphérique USB ?

#32 Le 02/04/2013, à 23:28

Re : Comment trouver le driver ou le chipset d'un périphérique USB ?

Pied de page des forums