Bonjour,
une question qui me taraude depuis un moment déjà...
J'aurai envie de développer une application dans un langage que j'affectionne (à savoir Python,C, ou java, par ordre de préférence du moment) et qui aurait besoin d'accéder au port USB.
Plus concrètement, mon 1er objectif est de pouvoir dialoguer avec un périphérique tel que mon téléphone portable, afin de récuperer par exemple les messages stockés dans la carte sim. (il est reconnu comme périphérique de masse, mais les messages ne sont pas stockés sur le memorystick...)
Bref, toute information sur le sujet est donc la bienvenue, et si il y a des outils existant de diagnostique permettant par exemple d'afficher le traffic sur le port (cf. ethereal), je veux bien aussi !
Sinon, ca me laisse perplexe ces logiciels non-officiels qui voient le jour et dont le but est de synchroniser les tel portables. Sans spécification ni rien de la part du constructeur, ils font comment pour developper leurs softs hein ??
Merci beaucoup beaucoup !
Forum Programmation.autre Ca marche comment, l'USB ?
9
déc.
2005
# specs
Posté par cho7 (site web personnel) . Évalué à 2.
Je ne pense pas que ca va m'aider (au contraire, j'vais être dégouté vu la taille de la doc!), mais bon...
[^] # Re: specs
Posté par TheBreton . Évalué à 4.
Elle n'ait utilise que si tu design un composants usb de base (niveau silicium on un hots ou un hub)..bref rien a voir avec la vie du programmeurs qui ne ferait pas de la gestion de couche basse.
Ces couches basse sont deja codé dans le kernel tu n'as pas réellement besoin de mettre les mains la dedans.
Sauf si ca te plait :-)
[^] # Re: specs
Posté par cho7 (site web personnel) . Évalué à 1.
# un coup de pouce
Posté par TheBreton . Évalué à 6.
Bin non, le seul langage qui peut accéder au composant usb c'est du C et qui tourne dans le kernel.Par contre tu peut trouver des drivers simple permettant de faire deja deux ou trois truc pour emettre et recevoir de données par l'usb (voir libusb[1]) qui peuvent etre apellé par divers langage..
Bref, toute information sur le sujet est donc la bienvenue, et si il y a des outils existant de diagnostique permettant par exemple d'afficher le traffic sur le port (cf. ethereal), je veux bien aussi !
Sinon, ca me laisse perplexe ces logiciels non-officiels qui voient le jour et dont le but est de synchroniser les tel portables.
Je joins les deux topics pour une réponse unie, les portages de soft sont souvent fait en espionnant les traffics usb sous windows avec (snoopy [2] (soft gpl), ou usbagent (soft+hard proprio) ou autre analyseur d'échange usb) et ensuite il faut se casser la tete pour interpreter les données.
Sans spécification ni rien de la part du constructeur, ils font comment pour developper leurs softs hein ??
Les gens qui bossent pour les contructeur on quelque fois un linux chez eux ou un copains qui utilisent linux et moyennant quelques bieres et cacahouette il est possible d'obtenir deux ou trois infos de manieres non-officielles....
[1] http://libusb.sourceforge.net/
[2] http://sourceforge.net/projects/usbsnoop/
[^] # Re: un coup de pouce
Posté par cho7 (site web personnel) . Évalué à 3.
Déjà, je dois reperer le bon periphérique dans la liste, et ca, à moins de me les taper 1 par 1, je vois pas comment optimiser la manip :) (j'ai déjà tué ma souris usb 2 fois en faisant un install & restart depuis snoopy!)
Bref, j'en ai pris 1 au pif dans la liste, et g intercepté mes 1ères trames usb. Mon dieu quelle horreur... C'est plus compliqué qu'un paquet IP :-D
J'vais ensuite jetter un oeil à la libusb, enfin, p'tetre ce soir, sinon le patron va raler :)
J'sens que j'vais vite être dégouté par l'affaire, mais pour l'instant j'tiens bon.
Merci beaucoup pour ton aide en tout cas
[^] # Re: un coup de pouce
Posté par TheBreton . Évalué à 1.
sous linux tu fait un lsusb -vv
tu repere la valeur de vendor-id et product-id
ces valeur la sont les XXX et YYY de
USB\Vid_XXXX&Pid_YYYY
des clefs snoopy.
Non les trames USB sont beaucoup plus simple que les trames IP.
Snoopy n'intercepte que les données échangé entre le pc et le device, les infos de trame et de routage sont otées.
[^] # Re: un coup de pouce
Posté par cho7 (site web personnel) . Évalué à 3.
Sinon pour les trames USB, c'est quoi le plus pertinent ? la colonne data je suppose ?
J'peux pas encore zieuter la libusb (ce soir...), mais en gros si je veux "cloner" une communication que j'aurai écouté, j'ai juste besoin de relever le champs "data" de la trame que le pc envoit au téléphone, et l'envoyer au périphérique via la libusb, et ce dernier va aussi me retourner un bloc data, comme une simple session telnet ? ou bien y a t il des données supplémentaires à envoyer lors de l'envoi de data vers le périphérique ? (en plus des data elles-mêmes)
[^] # Re: un coup de pouce
Posté par TheBreton . Évalué à 2.
Pile poile ce qu'il faut faire, apres il faut essayer de deviner quoi faire de ce qu'il te repond et les variations des questions à poser.
Il y as trois type de transaction Host-Device, des interrupts (une trame de donnée emisé toues les N milli-seconde par le device (enfin non mais fait comme si,taille max 64 octet)), des transactions bulk sur requete de l'host (quand il as envie de lire ou ecrire dans le device taille max 512 en usb1.1 ou 1024 en usb2.0) et des transaction isochrone.
libusb ne gerait pas les transaction interrupt la derniere fois que je l'ai regarder (d'ailleur je ne vois pas comment il pourrait le faire mais bon).
par contre je pense que tout faire en bulk est possible.
En general on mets des infos de status du device dans les trames interrupt et l'echange de donnée dans les trames bulk.
[^] # Re: un coup de pouce
Posté par cho7 (site web personnel) . Évalué à 2.
Sinon j'espere que les trames interrupts sont gérées de manières transparente, car si j'attend une réponse bulk et qu'elle est noyée dans les interrupts, pas glop
[^] # Re: un coup de pouce
Posté par TheBreton . Évalué à 2.
OUI c'est ca !
Sinon j'espere que les trames interrupts sont gérées de manières transparente, car si j'attend une réponse bulk et qu'elle est noyée dans les interrupts, pas glop
C'est géré plus bas dans linux, avec libusb tu ne pourra faire que j'envoie une trame bulk, j'attend une trame bulk de réponse.
Donc dans ton cas cela t'arrange.
[^] # Re: un coup de pouce
Posté par cho7 (site web personnel) . Évalué à 2.
Parcontre pour la suite ca s'annonce mal. Ca me parait super compliqué cette histoire. J'ai regardé le source de FMA (une appli windows ecrite en delphi, et special sony ericsson), et le fichier de source gsm_sms.pas me donne la nausée :$
Bref, je crois que j'ai visé un chouilla trop haut par rapport à ma motivation du moment (et mes compétences)...
Quoiqu'il en soit c'est gentil de m'avoir répondu, j'aurai appris quelques trucs :)
# En Python, C, Java
Posté par jayp . Évalué à 1.
[^] # Re: En Python, C, Java
Posté par cho7 (site web personnel) . Évalué à 2.
Sur sourceforge, il me dit qu'il n'y a pas de fichier dispo, sur le site de berlios http://developer.berlios.de/projects/pyusb idem.
Bref, c'est un vaporware ou t'as testé ?
# Tiens j'ai eu la même idée....
Posté par jeje99 . Évalué à 1.
Ce que je vais te dire fonctionne pour un sagem Myx5 mais je pense que c'est comme ça pour la plupart des téléphonnes.
En fait, sur mon téléphonne la sortie est un port série auquel se branche cable (vendu hors de prix par Sagem). Le cable utilisé pour communiquer avec mon téléphonne contient un chip qui émule un port série, et moi je suis très chanceux, car il exite un driver pour Linux pour piloter ce chip (je ne me souviens plus de référence du chip). Ce qui fait que je peux communiquer avec mon téléphone portable à l'aide du périphérique piloter à l'aide du driver (sous ubunutu /dev/ttyUSBX).
"Il ne reste plus" qu'à espionner le protocole série utilisé sous Windows par les appli fournies par le constructeur à l'aide d'un sniffeur de port série (je ne me souviens plus du nom du soft aussi désolé) et refaire la séquence dans le langage de programmation que tu veux (tu as juste à pouvoir avoir le périphérique /dev/ttyUSBX en lecture et écriture).
Il faut donc d'abord que tu regardes le cable que tu as :
- branche ton cable
- fait un lsusb
et normalement tu devrais voir le chip utiliser par ton cable, il ne reste plus qu'a vérifier si il est supporté par linux (si c'est non, il va falloir développé un driver avant)
Pour finir, je ne pense pas qu'il existe d'application complète de ce genre (je peux me tromper), je pense donc qu'il serait pas mal que tu penses ton application de manière générique de manière à ce d'autre propriétaire de téléphonne portable et de cable data linuxien et motivé puis ajouter facilement la gestion de leur portable à ton application (non non je ne pense pas à moi :-p).
[^] # Re: Tiens j'ai eu la même idée....
Posté par jeje99 . Évalué à 0.
Mais ton problème m'intéresse, ce que je voulais dire c'est pourquoi tu t'embète à chercher des trames USB, alors qu'il y a de très grosses chance pour qu'il existe, un driver pour le chip contenu dans le cable qui relie ton tél portable à ton PC.
Ce qui fait que t'aurais plus qu'à analyser des trames série classique et non des trames USB...
[^] # Re: Tiens j'ai eu la même idée....
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 3.
Et fondamentalement espionne une comm usb ou une comm serie
c'est pareil faut devinr qui fait quoi.
[^] # Re: Tiens j'ai eu la même idée....
Posté par cho7 (site web personnel) . Évalué à 2.
Maintenant je ne suis pas sous linux au taf, donc je ne saurai te dire dans l'immédiat si mon chip de mon cable a un driver ou non.
[^] # Re: Tiens j'ai eu la même idée....
Posté par jeje99 . Évalué à 1.
- mon palm m500,
- mon téléphone sagem myX5
- le tél de mon père motorola m925
J'ai pas dit que c'était comme ça pour tous.
Maintenant si c'est à but pédagogique, rien ne t'empèche de t'amuser avec les trames USB. Mais si c'est juste pour faire dans le protocolaire, je te rassure, il y a de fortes chances que ton téléphonne utilise un protocole ppp (rfc 1661) au dessus de l'usb.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.