./1
- Posté le 19/01/2011 à 12:35 Membre depuis le 14/01/2008, 35 messages
Bonjour,
Après plusieurs recherches infructueuses, je poste pour savoir comment faire pour transférer des données sur le port usb de la 89ti.
Il me semble qu'il faut gérer des interruptions sur le port usb, et placer les données à l'adresse du port ( 0x893C ) ???
Un document complet serait le bienvenu.
Merci
./2
- Posté le 19/01/2011 à 13:33 Membre depuis le 27/04/2006, 43544 messages
Pourquoi avoir ouvert un nouveau sujet ? #confus#
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
./3
- Posté le 19/01/2011 à 13:56 Membre depuis le 16/06/2001, 59942 messages
godbod (./2) :
Un document complet serait le bienvenu.
et plus vite que ça.
./4
- Posté le 19/01/2011 à 14:20 Membre depuis le 18/06/2001, 30157 messages
Ben il demande un tuto et remercie #confus#
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
./5
- Posté le 19/01/2011 à 22:39 Membre depuis le 14/01/2008, 35 messages
Zerosquare (./2) :
Pourquoi avoir ouvert un nouveau sujet ? #confus#

J'ai tout simplement pensé que ce sujet susciterais beaucoup d'attention et de questions "de ma part en tout cas". A force de trop vouloir subdiviser les problèmes en plus petits, j'ai voulu séparer les deux postes... Mais si ça dérange vraiment, il faurdrait l'effacer et reprendre sur le premier ? #roll#

squalyl (./3) :
godbod (./2) :
Un document complet serait le bienvenu.
et plus vite que ça.


???? j'ai pas du tout voulu dire ça... non du tout ... je remercie d'avance une personne qui m'apporterait son aide. Ce sujet me tient à coeur. smile
Bonne soirée.
./6
- Posté le 19/01/2011 à 23:21 Membre depuis le 16/06/2001, 59942 messages
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
./7
- Posté le 19/01/2011 à 23:30 Membre depuis le 27/04/2006, 43544 messages
(t'es sûr pour le sens des tokens IN/OUT ? dans mon souvenir, c'était l'inverse, mais j'ai pas touché à l'USB depuis des lustres)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
./8
- Posté le 20/01/2011 à 00:01 Membre depuis le 16/06/2001, 59942 messages
non, je suis pas sur, c'est à vérifier. Mais ça m'avait choqué, donc ça devait être le truc "pas normal" (genre in = lecture sur le device)

vala:

paquets:
# In - Informs the USB device that the host wishes to read information.
# Out - Informs the USB device that the host wishes to send information.

c'est pareil les endpoints
un EP IN sert aux transferts device->host
un EP OUT sert aux transferts host->device

endpoint.gif
./9
- Posté le 20/01/2011 à 15:01 Membre depuis le 14/01/2008, 35 messages
Okay, merci je comprends un peu mieux le programme de Brandom maintenant ... le fameux jail break de la PS3... !!! smile
A bientot
- Posté le 20/01/2011 à 20:16 Membre depuis le 27/04/2006, 43544 messages
squalyl : ouais voilà, c'est bien ce dont je me souvenais smile
Le sens IN/OUT est considéré du point de vue de l'hôte, en fait (vu que c'est lui qui envoie les tokens).
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
- Posté le 03/06/2011 à 23:37 Membre depuis le 14/01/2008, 35 messages
j'avoue que c'est complexe tout ça...
- Posté le 04/06/2011 à 09:14 Membre depuis le 28/10/2001, 7568 messages
Plutôt, oui.
L'USB, c'est simple pour les utilisateurs, mais merdique pour les programmeurs smile
avatar Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
- Posté le 04/06/2011 à 22:55 Membre depuis le 14/01/2008, 35 messages
Oui j'avoue. J'essaie actuellement faire un programme minimaliste à partir du porgramme de BrandomW (Jail Break PS3) Je veux juste écouter les paquets USB arrivant sur la ti.
Il y a un truc que je comprends pas dans le style de programmation de Brandom, il met les prototypes dans le fichier main mais il implémente les fonctions dans d'autre fichiers...
- Posté le 05/06/2011 à 08:44 Membre depuis le 18/06/2001, 30157 messages
Ben ça change quoi en fait ? Il pourrait les mettre dans un header et inclure ce header, ça serait pareil cheeky
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
- Posté le 05/06/2011 à 13:10 Membre depuis le 14/01/2008, 35 messages
Rien de grave en fait... #roll# tu peux pas savoir, en cours on est noté pour la structuration de nos programmes... lol
- Posté le 05/06/2011 à 14:38 Membre depuis le 28/10/2001, 7568 messages
BrandonW pourrait en effet utiliser des headers pour déclarer les prototypes plutôt que le main, mais ça n'est pas trop grave en effet, tant que les prototypes sont synchronisés smile

tu peux pas savoir, en cours on est noté pour la structuration de nos programmes...

Pas tout ce qu'on apprend en cours n'est applicable dans le cadre d'une programmation sur plate-forme embarquée, qui plus est dans le cadre du hobby wink
Pour ne citer qu'un exemple: en cours, je doute qu'on ne t'ait pas appris que "goto", c'est mal. Et qu'on te l'ait dit plutôt trois fois qu'une.
Mais dans le monde réel, quand on programme sur plate-forme embarquée, il est intéressant d'utiliser des goto à bon escient (faut pas faire n'importe quoi, évidemment ^^), pour des raisons d'efficacité.
avatar Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
- Posté le 05/06/2011 à 16:00 Membre depuis le 14/01/2008, 35 messages
hum... merci pour le conseil... #chinois#. Par contre j'ai 2 questions qui me tracassent,

../..

// il s'agit d'un code sur le traitement de commandes envoyées par un host USB.

switch (command)
		{
			case 0x12: //inquiry
			{
				//Send back what it wants
				unsigned char response[36] = {0};
				
				response[1] = 0x80; //removable media
				response[3] = 0x01; //because the UFI spec says so
				response[4] = 0x1F; //additioanl length
				memcpy(response+8, "BrandonW", 8);
				memcpy(response+16, "USB Flash Drive", 15);
				memcpy(response+32, "0.01", 4);
				
				//Send it off
				USB_SendBulkData(0x01, response, 36);
				break;
			}
../..



1. dans ce code source, les lignes suivantes :
memcpy(response+8, "BrandonW", 8);
				memcpy(response+16, "USB Flash Drive", 15);
				memcpy(response+32, "0.01", 4);


correspondent elles à la description d'un paquet de quelle taille ? à mon avis il s'agit d'un paquet de 64 octets ??? et pourquoi écrire à ces endroits précis ?

2. l'envoi de bulk :
USB_SendBulkData(0x01, response, 36);


le chiffre en hexadécimal, 0x01 correspond t-il au descripteur d'Appareil du protocole USB ?
- Posté le 08/07/2011 à 00:07 Membre depuis le 14/01/2008, 35 messages
up, en fait selon Brandon, le 0x01 serait en fait l'endpoint sur lequel on communique. Pour la taille je me demande toujours...
- Posté le 08/07/2011 à 00:11 Membre depuis le 27/04/2006, 43544 messages
C'est expliqué dans la doc USB officielle (bon courage ! grin)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
- Posté le 08/07/2011 à 12:19 Membre depuis le 14/01/2008, 35 messages
oui d'après la doc justement il s'agit d'un paquet de 64 octets, ce que m'a confirmé Brandon. Cependant j'ai posé la question parce que si je calcul manuellement, je tombe sur un paquet de 36 octets en fait.
Personnellement je sais pas que fait on des 28 octets qui restent... #confus#