./1
- Posted On the 2011-01-19 at 12:35 pm Member since 2008-01-14, 35 posts
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
- Posted On the 2011-01-19 at 01:33 pm Member since 2006-04-27, 44074 posts
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
- Posted On the 2011-01-19 at 01:56 pm Member since 2001-06-16, 60268 posts
godbod (./2) :
Un document complet serait le bienvenu.
et plus vite que ça.
./4
- Posted On the 2011-01-19 at 02:20 pm Member since 2001-06-18, 30670 posts
Ben il demande un tuto et remercie confus
avatar <<< Kernel Extremist©®™ >>>
Saint Qt, priez pour nous.
./5
- Posted On the 2011-01-19 at 10:39 pm Member since 2008-01-14, 35 posts
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
- Posted On the 2011-01-19 at 11:21 pm Member since 2001-06-16, 60268 posts
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
- Posted On the 2011-01-19 at 11:30 pm Member since 2006-04-27, 44074 posts
(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
- Posted On the 2011-01-20 at 12:01 am Member since 2001-06-16, 60268 posts
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
- Posted On the 2011-01-20 at 03:01 pm Member since 2008-01-14, 35 posts
Okay, merci je comprends un peu mieux le programme de Brandom maintenant ... le fameux jail break de la PS3... !!! smile
A bientot
- Posted On the 2011-01-20 at 08:16 pm Member since 2006-04-27, 44074 posts
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
- Posted On the 2011-06-03 at 11:37 pm Member since 2008-01-14, 35 posts
j'avoue que c'est complexe tout ça...
- Posted On the 2011-06-04 at 09:14 am Member since 2001-10-28, 7581 posts
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.
- Posted On the 2011-06-04 at 10:55 pm Member since 2008-01-14, 35 posts
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...
- Posted On the 2011-06-05 at 08:44 am Member since 2001-06-18, 30670 posts
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.
- Posted On the 2011-06-05 at 01:10 pm Member since 2008-01-14, 35 posts
Rien de grave en fait... roll tu peux pas savoir, en cours on est noté pour la structuration de nos programmes... lol
- Posted On the 2011-06-05 at 02:38 pm Member since 2001-10-28, 7581 posts
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.
- Posted On the 2011-06-05 at 04:00 pm Member since 2008-01-14, 35 posts
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 ?
- Posted On the 2011-07-08 at 12:07 am Member since 2008-01-14, 35 posts
up, en fait selon Brandon, le 0x01 serait en fait l'endpoint sur lequel on communique. Pour la taille je me demande toujours...
- Posted On the 2011-07-08 at 12:11 am Member since 2006-04-27, 44074 posts
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
- Posted On the 2011-07-08 at 12:19 pm Member since 2008-01-14, 35 posts
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