quelques infos, mais en gros on va répéter ce qui a déja été dit:
1 - il y a très peu d'infos sur ce port usb
2 - envoyer des données sur un port usb ne veut rien dire. un port usb n'est pas du tout comme un port série , ou même le port link des anciens modèles.
Tu ne peux pas envoyer un truc comme "hello world" et le récupérer sur le PC.
D'ailleurs , USB n'est pas un port mais un BUS.
cela veut dire qu'il faut des développements complexes pour en suivre le protocole à la lettre.
Je vais en dire ce que je sais.
Sur la paire D+/D-, on envoie des paquets de données formattés très spécialement. Ce niveau n'est pas géré par du logiciel mais par un bloc hardware appelé Serial Interface Engine (SIE). Ce bitoniau formate les paquets, ajoute les parités, et s'assure que les lignes de données ne restent pas trop longtemps à zéro ou à un, afin de pouvoir reconstituer facilement l'horloge. Ca s'appelle le bit stuffing et on a pas à s'en occuper.
Chaque paquet correspond à une "request", le PC commence toujours à envoyer une request, et le périphérique répond.
Un bus USB supporte 127 périphériques.
Un périphérique est composé d'endpoints, qui sont de petits FIFO dans le périphérique (la TI) que le PC pourra remplir ou demander à lire.
La configuration précise de ces 'endpoints' est définie dans ce qu'on appelle des descripteurs. Il y a des descripteurs de périphériques, de configuration, d'interface, de fonction et d'endpoints.
Au moment ou le périphérique est branché, il prend automatiquement l'adresse ZERO. Le PC lui envoie alors une request pour que le périphérique réponde avec son descripteur de périphérique. a ce moment, windows peut afficher "Nouveau périphérique détecté".
Le PC demande ensuite les descripteurs de chaines et a ce moment, windows peut afficher le nom du bidule branché.
le PC demande alors au périphérique (je vais écrire device, c'est plus rapide) de lui donner ses descripteurs d'interface. A ce moment, le PC peut utiliser cette info pour charger un pilote, ou utiliser un pilote interne si il reconnait une configuration standard comme "souris" "clé USB" ou "clavier".
Quand le PC a bien accepté le périphérique, il affecte une adresse au périphérique. Il est alors prêt à accepter une autre connexion sur le bus.
Maintenant, pour communiquer.
- soit le PC a un truc a dire au périphérique. Ton pilote va créer une request "write" (je crois qu'on l'appelle IN car on se met a la place du device) avec des données applicatives destinées à un des endpoints. l'OS du PC décide quand il doit l'envoyer. Quand le SIE du device reçoit le paquet, il le place dans le FIFO correspondant puis génère une interruption. Le device se réveille et fait ce qu'il faut avec ces données.
- soit le device a un truc à dire au PC. ATTENTION subtil c'est plus compliqué. Le device ne peut pas parler au PC. Tout ce qu'il peut faire, c'est remplir un endpoint qui a été configuré en OUT. Et c'est le PC qui interroge régulièrement. A l'interrogation suivante, le PC démarre la lecture, puis le SIE génère une IRQ dans le device pour dire "lecture terminée". A ce moment le device peut se préparer pour mettre les données suivantes dans le FIFO.
Donc 'envoyer des données sur le port usb de la ti', tu vois, c'est un peu compliqué car il faut savoir comment configurer tout ça. Ca implique des tas de registres à positionner correctement dans la TI, et donc pas mal de logiciel à écrire. Tu t'en sortiras pas avec une sorte de puts("coucou");
Et ce qui nous manque donc, c'est la doc de tous ces ports, des efforts ont été faits pour reverse engineerer tout ça mais c'est pas gagné, sur la ti89ti.
Et donc ne parlons même pas de la possibilité pour la ti d'accepter des périphériques. C'est possible, car ce sont des devices USB OTG (on the go) mais c'est encore plus complexe, car c'est à la calc de s'occuper des associations de périphériques.
Je tire la plupart de ce que j'ai compris d'ici :
http://www.beyondlogic.org/usbnutshell/usb1.shtml
. Par contre j'ai 2 questions qui me tracassent,
)