Inventer la bibliothèque vusb

Présentation

Après avoir lu le titre, une question logique peut se poser: pourquoi étudier aujourd'hui l'implémentation logicielle de l'USB bas débit alors qu'il existe un tas de contrôleurs bon marché avec un module matériel? Le fait est que le module matériel, cachant le niveau d'échange des niveaux logiques, transforme le protocole USB en une sorte de magie. Pour ressentir le fonctionnement de cette «magie», rien de mieux que de la reproduire à partir de zéro, à partir du niveau le plus bas.

À cette fin, nous allons essayer de fabriquer un appareil prétendant être USB-HID basé sur le contrôleur ATmega8. Contrairement à la littérature répandue, nous n'irons pas de la théorie à la pratique, du niveau le plus bas au plus élevé, des tensions logiques aux conclusions, et nous terminerons par l '«invention» de la même vusb, après chaque étape vérifiant si le code fonctionne comme prévu. Séparément, je note que je n'invente pas d'alternative à cette bibliothèque, mais plutôt, je reproduis constamment son code source, en préservant autant que possible la structure et les noms d'origine, expliquant pourquoi telle ou telle section sert. Cependant, mon style habituel d'écriture de code est différent du style des auteurs vusb. Immédiatement, j'avoue honnêtement qu'en plus de l'intérêt altruiste (pour raconter un sujet difficile aux autres), j'ai aussi un intérêt égoïste - étudier le sujet par moi-même et attraper un maximum de points subtils pour moi-même. Il s'ensuit également qu'un point important peut être manqué ou qu'un sujet n'est pas entièrement divulgué.

Pour une meilleure compréhension du code, j'ai essayé de mettre en évidence les sections modifiées avec des commentaires et de les supprimer des sections discutées précédemment. En fait, le code source sera la principale source d'information, et le texte expliquera ce qui a été fait et pourquoi, ainsi que le résultat attendu.

Je note également que seul l'USB à bas débit est pris en compte, même sans mentionner, ce qui distingue les variétés les plus rapides.

Étape 0. Fer et autres préparations

Comme test, prenons une carte de débogage maison basée sur ATmega8 avec du quartz 12 MHz. Je ne donnerai pas le schéma, il est assez standard (voir le site officiel vusb), la seule chose qui mérite d'être mentionnée est les conclusions utilisées. Dans mon cas, la sortie D + correspond à PD2, la sortie D-PD3, et la bretelle se bloque sur PD4. En principe, une résistance de rappel pourrait être connectée à l'alimentation, mais le contrôle manuel semble un peu plus conforme à la norme.

Une alimentation de 5 V est fournie par le connecteur USB, cependant, on ne s'attend pas à plus de 3,6 V sur les lignes de signal (pourquoi était-ce un mystère pour moi). Vous devez donc soit réduire la puissance du contrôleur, soit placer les diodes zener sur les lignes de signal. J'ai choisi la deuxième option, mais dans l'ensemble, cela n'a pas d'importance.

Puisque nous «inventons» l'implémentation, il serait agréable de voir ce qui se passe dans le cerveau du contrôleur, c'est-à-dire qu'au moins une sorte d'informations de débogage est nécessaire. Dans mon cas, ce sont deux LED sur PD6, PD7 et, surtout, UART sur PD0, PD1, configurées sur 115200, afin que vous puissiez écouter le bavardage du contrôleur via un écran normal ou un autre programme pour travailler avec le port COM:

$ screen /dev/ttyUSB0 115200 

De plus, un wirehark avec le module approprié se révélera être un utilitaire utile pour le débogage USB (il ne démarre pas toujours à partir de la boîte, mais la résolution de ces problèmes se trouve assez bien sur Internet et ce n'est pas la tâche de cet article).

Ici, il serait possible de dépenser un autre kilo-octet de texte pour la description du programmeur, des makefiles et d'autres choses, mais cela n'a guère de sens. De même, je ne me concentrerai pas sur les paramètres périphériques qui ne sont pas liés à l'USB. Si quelqu'un ne peut même pas comprendre cela, est-il trop tôt pour entrer dans les entrailles du logiciel USB?

Le code source de toutes les étapes est disponible sur Github.

Étape 1. Acceptez au moins quelque chose

Selon la documentation, l'USB prend en charge plusieurs vitesses fixes, dont l'AVR ne tirera que le plus bas: 1,5 mégabits par seconde. Elle est déterminée par la résistance de rappel et la communication ultérieure. Pour notre fréquence choisie, la résistance doit connecter D- avec une alimentation de 3,3 V et avoir une valeur nominale de 1,5 kOhm, mais en pratique, elle peut être connectée avec +5 V et la valeur nominale peut varier légèrement. Avec une fréquence de contrôleur de 12 MHz, seulement 8 cycles d'horloge par bit. Il est clair qu'une telle précision et vitesse ne sont réalisables que dans l'assembleur, nous allons donc ouvrir le fichier drvasm.S. Cela implique également la nécessité d'utiliser une interruption pour intercepter le début d'un octet. Je suis heureux que le premier octet transmis via USB soit toujours le même, SYNC, donc si vous arrivez au début, ça va. Par conséquent, du début de l'octet à sa fin, seuls 64 cycles de contrôleur passent (en fait, la marge est encore plus petite), vous ne devez donc pas utiliser d'autres interruptions non USB.

Mettez immédiatement la configuration dans un fichier usbconfig.h distinct. C'est là que seront fixées les broches responsables de l'USB, ainsi que les bits, constantes et registres utilisés.

Encart théorique
Le transfert via USB s'effectue en paquets de plusieurs octets chacun. Le premier octet est toujours l'octet de synchronisation SYNC, égal à 0b10000000, le second est l'identifiant d'octet du paquet PID. Le transfert de chaque octet passe du bit le moins significatif au plus significatif (ce n'est pas tout à fait vrai, mais en subtilité cette subtilité est ignorée, donnée ailleurs) en utilisant le codage NRZI. Cette méthode consiste dans le fait qu'un zéro logique est transmis en changeant le niveau logique à l'opposé, et une unité logique est transmise par non-changement. De plus, une protection est introduite contre la désynchronisation (que nous n'utiliserons pas, mais doit être prise en compte) de la source et du récepteur du signal: s'il y a six unités d'affilée dans la séquence transmise, c'est-à-dire que l'état des terminaux ne change pas pendant six périodes consécutives, une inversion forcée est ajoutée à la transmission, comme si zéro est transmis. Ainsi, la taille des octets peut être de 8 ou 9 bits.
Il convient également de mentionner que les lignes de données en USB sont différentielles, c'est-à-dire que lorsque D + est élevé, D- il est faible (c'est ce qu'on appelle l'état K) et vice versa (état J). Ceci est fait pour une meilleure immunité au bruit à haute fréquence. Certes, il y a une exception: le signal à la fin du paquet (il s'appelle SE0) est transmis en tirant les deux lignes de signal vers le sol (D + = D- = 0). Il y a deux autres signaux transmis en maintenant une basse tension sur la ligne D + et une haute tension sur la ligne D + pendant des moments différents. Si le temps est petit (une longueur d'octet ou un peu plus long) alors c'est Idle, une pause entre les paquets, et s'il est grand, un signal de réinitialisation.

Ainsi, la transmission se fait sur une paire différentielle, sans compter le cas exotique de SE0, mais nous ne le considérerons pas encore. Ainsi, pour déterminer l'état du bus USB, nous n'avons besoin que d'une seule ligne, D + ou D-. Dans l'ensemble, il n'y a aucune différence à choisir, mais pour être précis, laissez D- être.

Le début du paquet peut être déterminé en recevant l'octet SYNC après un long repos. L'état inactif correspond à log.1 sur la ligne D (c'est également l'état J), et l'octet SYNC est 0b100000, mais il est transmis du bit le moins significatif au bit le plus significatif, de plus, il est codé en NRZI, c'est-à-dire que chaque zéro signifie l'inversion du signal et un moyen maintenir le même niveau. La séquence des états D- sera donc la suivante:

Le début du paquet est plus facile à détecter sur un front descendant, et nous allons configurer une interruption sur celui-ci. Mais que se passe-t-il si le contrôleur est occupé au début de la réception et ne peut pas entrer immédiatement l'interruption? Afin d'éviter de perdre le nombre de pistes dans une telle situation, nous utilisons l'octet SYNC pour sa destination. Il se compose entièrement de fronts aux limites des bits, de sorte que nous pouvons attendre l'un d'eux, puis un autre demi-bit, et aller directement au milieu du suivant. Cependant, attendre un «certain» front n'est pas une bonne idée, car nous devons non seulement entrer au milieu du bit, mais aussi savoir quel bit nous avons obtenu dans le score. Et pour cela, SYNC convient également: il a deux bits zéro consécutifs à la fin (ce sont des états K). Ici, nous les attraperons. Ainsi, dans le fichier drvasm.S, un morceau de code apparaît à partir de l'entrée d'interruption vers foundK. De plus, en raison du temps nécessaire pour vérifier l'état du port, pour une transition inconditionnelle et ainsi de suite, nous arrivons à la marque non pas au début du bit, mais juste au milieu. Mais il est inutile de vérifier la même chose, car nous connaissons déjà sa signification. Par conséquent, nous attendons 8 cycles d'horloge (jusqu'à présent nop'ami vide) et vérifions le bit suivant. S'il est également nul, alors nous avons trouvé la fin de SYNC et pouvons procéder à la réception de bits significatifs.

En fait, tout le code supplémentaire est destiné à lire deux octets supplémentaires avec une sortie ultérieure vers UART. Eh bien, en attendant l'état de SE0 pour ne pas entrer accidentellement dans le prochain paquet.

Vous pouvez maintenant compiler le code résultant et voir quels octets notre appareil accepte. Personnellement, j'ai la séquence suivante:

 4E 55 00 00 4E 55 00 00 4E 55 00 00 4E 55 00 00 4E 55 00 00 

N'oubliez pas que nous générons des données brutes, à l'exclusion des zéros incrémentiels et du décodage NRZI. Essayons de décoder manuellement, en commençant par le bit bas:

Il n'est pas logique de décoder des zéros, car 16 valeurs identiques consécutives ne peuvent pas être incluses dans un paquet.

Ainsi, nous avons pu écrire un firmware qui accepte les deux premiers octets du paquet, mais jusqu'à présent sans décodage.

Étape 2. Version de démonstration de NRZI

Afin de ne pas recoder manuellement, vous pouvez confier cela au contrôleur lui-même: l'opération XOR fait exactement ce dont vous avez besoin, bien que le résultat soit inversé, alors ajoutez une autre inversion après:

 mov temp, shift lsl shift eor temp, shift com temp rcall uart_hex 

Le résultat est tout à fait attendu:

 2D 00 FF FF 2D 00 FF FF 2D 00 FF FF 2D 00 FF FF 2D 00 FF FF 

Étape 3. Débarrassez-vous du cycle de réception d'octets

Prenons un petit pas de plus et élargissons le cycle de réception du premier octet dans un code linéaire. Ainsi, il s'avère que beaucoup de nops, nécessaires uniquement pour attendre le début du bit suivant. Au lieu de certains d'entre eux, vous pouvez utiliser le décodeur NRZI, d'autres vous seront utiles plus tard.

Le résultat de l'option précédente n'est pas différent.

Étape 4. Lire dans le tampon

La lecture dans des registres séparés est, bien sûr, rapide et belle, mais quand il y a trop de données, il est préférable d'utiliser une entrée de tampon située quelque part dans la RAM. Pour ce faire, nous déclarerons un tableau de taille suffisante dans le main, et dans l'interruption nous y écrirons.
Encart théorique

La structure des paquets en USB est normalisée et se compose des parties suivantes: octet SYNC, octet PID + CHECK (2 champs de 4 bits chacun), champ de données (parfois 11 bits, mais le plus souvent un nombre arbitraire d'octets 8 bits) et une somme de contrôle CRC de 5 ( pour un champ de données de 11 bits), ou 16 (pour le reste) bits. Enfin, l'indication de fin de paquet (EOP) est de deux bits de pause, mais ce ne sont plus des données.

Avant de travailler avec le tableau, vous devez toujours configurer les registres et libérer nop avant que le premier bit ne soit pas suffisant pour cela. Par conséquent, vous devrez mettre la lecture des deux premiers bits dans la section linéaire du code, entre les commandes dont nous insérerons le code d'initialisation, puis sauter au milieu du cycle de lecture, sur l'étiquette rxbit2. En parlant de taille de tampon. Selon la documentation, dans un paquet, il est impossible de transférer plus de 8 octets de données. Nous ajoutons les octets de service PID et CRC16, nous obtenons une taille de tampon de 11 octets. Les octets SYNC et l'état EOP ne seront pas écrits. Nous ne serons pas en mesure de contrôler l'intervalle des demandes de l'hôte, mais nous ne voulons pas non plus les perdre, nous allons donc prendre une double marge pour la lecture. Pour l'instant, nous n'utiliserons pas l'intégralité du buffer, mais afin de ne pas revenir dans le futur, il est préférable d'allouer immédiatement le volume requis.

Étape 5. Travailler humainement avec le tampon

Au lieu de lire directement les premiers octets du tableau, nous écrivons un morceau de code qui lit exactement autant d'octets qu'il a été réellement écrit dans le tableau. Et en même temps, ajoutez un séparateur entre les packages.
Maintenant, la sortie ressemble à ceci:

 >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF 

Étape 6. Ajout d'un additif Zero Additive

Enfin, il est temps de terminer la lecture du flux binaire en standard. Le dernier élément dont nous avons réussi à nous passer était un faux zéro, ajouté toutes les six unités consécutives. Étant donné que la réception d'octets est déployée sur le corps linéaire de la boucle, vous devez vérifier après chaque bit, aux huit endroits. Considérez les deux premiers bits comme exemple:

 unstuff0: ;1 (  breq) andi x3, ~(1<<0) ;1 [15]  0-  .     mov x1, x2 ;1 [16]      () in x2, USBIN ;1 [17] <-- 1-   .     ori shift, (1<<0) ;1 [18]  0-   .1      rjmp didUnstuff0 ;2 [20] ;<---//---> rxLoop: eor shift, x3 ;1 [0] in x1, USBIN ;1 [1] st y+, shift ;2 [3] ldi x3, 0xFF ;1 [4] nop ;1 [5] eor x2, x1 ;1 [6] bst x2, USBMINUS ;1 [7]     0-   shift bld shift, 0 ;1 [8] in x2, USBIN ;1 [9] <--  1- (, ) andi x2, USBMASK ;1 [10] breq se0 ;1 [11] andi shift, 0xF9 ;1 [12] didUnstuff0: breq unstuff0 ;1 [13] eor x1, x2 ;1 [14]; bst x1, USBMINUS ;1 [15]     1-   shift bld shift, 1 ;1 [16] rxbit2: in x1, USBIN ;1 [17] <--  2-  (, ) andi shift, 0xF3 ;1 [18] breq unstuff1 ;1 [19] didUnstuff1: 

Pour la commodité de la navigation, les adresses des commandes décrites seront comptées par les étiquettes à droite. Veuillez noter qu'ils ont été introduits pour compter les cycles d'horloge du contrôleur, donc ils ne sont pas en ordre. L'octet suivant est lu sur l'étiquette rxLoop, l'octet précédent est inversé et écrit dans le tampon [0, 3]. Ensuite, sur l'étiquette [1], l'état de la ligne D est lu, selon XOR avec l'état accepté précédent, nous décodons NRZI (je rappelle que le XOR ordinaire ajoute son inversion, pour corriger ce que nous entrons dans le registre de masque x3, initialisé avec les unités 0xFF) et écrivons à 0- ième bit du registre à décalage [7,8]. Ensuite, le plaisir commence - nous vérifions si le bit reçu était le sixième inchangé. Le bit constant reçu avec D- correspond à l'écriture de zéro (pas un! Nous passerons à un à la fin, XOR) dans le registre. Par conséquent, vous devez vérifier si les bits 0, 7, 6, 5, 4, 3 sont des zéros. Les deux bits restants n'ont pas d'importance, ils sont restés de l'octet précédent et ont été vérifiés plus tôt. Pour s'en débarrasser, nous coupons le registre par le masque [12], où tous les bits qui nous intéressent sont mis à 1: 0b11111001 = 0xF9. Si après avoir appliqué le masque tous les bits se sont avérés être des zéros, la situation de l'ajout d'un bit est corrigée et il y a une transition vers l'étiquette unstuff0. Un bit de plus [17] y est lu au lieu de ce qui a été lu précédemment, dans l'intervalle entre les autres opérations, d'un excès [9]. Nous échangeons également les registres des valeurs actuelles et précédentes x1, x2. Le fait est que sur chaque bit, la valeur est lue dans un registre, puis XOR est dans un autre, après quoi les registres sont échangés. Par conséquent, lors de la lecture du registre incrémental, cette opération doit également être effectuée. Mais la chose la plus intéressante est que dans le registre de données à décalage, nous écrivons non pas le zéro, que nous avons reçu honnêtement, mais l'unité que l'hôte a tenté de transférer [18]. Cela est dû au fait que lors de la réception des bits suivants, la valeur de zéro devra également être prise en compte, et si nous avons enregistré zéro, la vérification du masque n'a pas pu découvrir que le bit supplémentaire a déjà été pris en compte. Ainsi, dans le registre à décalage, tous les bits sont inversés (par rapport à ceux transmis par l'hôte), et le zéro ne l'est pas. Pour éviter un tel gâchis dans le tampon, nous effectuerons une inversion inverse selon XOR non pas avec 0xFF [0], mais avec 0xFE, c'est-à-dire un registre dans lequel le bit correspondant sera réinitialisé à 0 et, par conséquent, ne conduira pas à une inversion. Pour ce faire, sur l'échantillon [15] et réinitialisez le bit zéro.

Une situation similaire se produit avec les bits 1-5. Disons que le 1er bit correspond à la vérification 1, 0, 7, 6, 5, 4, tandis que les bits 2, 3 sont ignorés. Cela correspond au masque 0xF3.
Mais le traitement des 6 et 7 bits est différent:

 didUnstuff5: andi shift, 0x3F ;1 [45]   5-0 breq unstuff5 ;1 [46] ;<---//---> bld shift, 6 ;1 [52] didUnstuff6: cpi shift, 0x02 ;1 [53]   6-1 brlo unstuff6 ;1 [54] ;<---//---> bld shift, 7 ;1 [60] didUnstuff7: cpi shift, 0x04 ;1 [61]   7-2 brsh rxLoop ;3 [63] unstuff7: 

Le masque du 6e bit est le numéro 0b01111110 (0x7E), mais vous ne pouvez pas le superposer sur le registre à décalage, car il réinitialisera le 0e bit, qui doit être écrit dans le tableau. De plus, au compte à rebours [45], un masque était déjà superposé, réinitialisant 7 bits. Par conséquent, il est nécessaire de traiter le bit supplémentaire si les bits 1-6 sont égaux à zéro et que le 0ème n'a pas d'importance. Autrement dit, la valeur du registre doit être 0 ou 1, ce qui est parfaitement vérifié en comparant "moins de 2" [53, 54].

Le même principe a été utilisé pour le 7e bit: au lieu d'appliquer le masque 0xFC, une vérification est effectuée pour «moins de 4» [61, 63].

Étape 7. Triez les packages

Puisque nous pouvons recevoir un paquet avec le premier octet (PID) égal à 0x2D (SETUP), nous essaierons de trier celui reçu. Au fait, pourquoi ai-je appelé le package 0x2D SETUP alors qu'il semble être ACK? Le fait est que la transmission USB du bit le moins significatif au bit le plus significatif est effectuée dans chaque champ, et non octet, alors que nous acceptons octet par octet. Le premier champ significatif, PID, ne prend que 4 bits, suivi de 4 bits CHECK supplémentaires, représentant une inversion au niveau du bit du champ PID. Ainsi, le premier octet reçu ne sera pas PID + CHECK, mais plutôt CHECK + PID. Cependant, il n'y a pas beaucoup de différence, car toutes les valeurs sont connues à l'avance et il est facile de réorganiser les grignotages par endroits. Tout de suite, nous écrirons les principaux codes qui peuvent nous être utiles dans le fichier usbconfig.h.

Nous n'avons pas encore commencé à ajouter le code de traitement PID, notez qu'il devrait être rapide (c'est-à-dire dans l'assembleur), mais l'alignement par horloge n'est pas requis, car nous avons déjà accepté le paquet. Par conséquent, cette section sera par la suite transférée dans le fichier asmcommon.inc, qui contiendra du code assembleur qui n'est pas lié à la fréquence. En attendant, mettez simplement le commentaire en surbrillance.
Passons maintenant au tri des paquets reçus.

Encart théorique
Les paquets de données sur le bus USB sont combinés en transactions. Chaque transaction commence par l'envoi par l'hôte d'un paquet marqueur spécial qui contient des informations sur ce que l'hôte veut faire avec le périphérique: configurer (SETUP), transmettre des données (OUT) ou les recevoir (IN). Après la transmission du paquet marqueur, une pause de deux bits s'ensuit. Ceci est suivi d'un paquet de données (DATA0 ou DATA1), qui peut être envoyé à la fois par l'hôte et le périphérique, en fonction du paquet marqueur. Ensuite, une autre pause de deux bits et la réponse est HANDSHAKE, un paquet de confirmation (ACK, NAK, STALL, nous les considérerons une autre fois).

CONFIGURATION		DATA0		Poignée de main
hôte-> appareil	pause	hôte-> appareil	pause	appareil-> hôte

OUT		DATA0 / DATA1		Poignée de main
hôte-> appareil	pause	hôte-> appareil	pause	appareil-> hôte

EN		DATA0 / DATA1		Poignée de main
hôte-> appareil	pause	appareil-> hôte	pause	hôte-> appareil

Étant donné que l'échange va sur les mêmes lignes, l'hôte et l'appareil doivent constamment basculer entre la transmission et la réception. De toute évidence, le délai de deux bits est précisément à cet effet et est fait pour qu'ils ne commencent pas à jouer push-push, tout en essayant de transférer simultanément certaines données sur le bus.

Nous connaissons donc tous les types de packages nécessaires à l'échange. Nous ajoutons une vérification de l'octet PID reçu pour la conformité avec chacun. Pour le moment, le périphérique n'est pas encore en mesure d'écrire même des paquets primitifs tels que ACK sur le bus, ce qui signifie qu'il est incapable de dire à l'hôte ce que c'est. Par conséquent, des commandes comme IN ne peuvent pas être attendues. Nous ne vérifierons donc que la réception des commandes SETUP et OUT, pour lesquelles nous indiquerons l'inclusion des LED correspondantes dans les branches correspondantes.

En outre, il vaut la peine de prendre l'envoi de journaux au-delà de l'interruption, quelque part dans le principal.

Nous flashons l'appareil avec ce qui s'est passé après avoir effectué ces modifications et observons la séquence suivante d'octets reçus:

 2D|80|06|00|01|00|00|40|00 C3|80|06|00|01|00|00|40|00 2D|80|06|00|01|00|00|40|00 C3|80|06|00|01|00|00|40|00 

Et en plus - les deux LED allumées. Nous avons donc pris SETUP et OUT.

Étape 8. Lisez l'adresse sur l'enveloppe

Encart théorique
Les paquets de marqueurs (SETUP, IN, OUT) servent non seulement à montrer au périphérique ce qu'ils en veulent, mais également à adresser un périphérique spécifique sur le bus et à un point de terminaison spécifique à l'intérieur. Des points de terminaison sont nécessaires pour mettre en évidence de manière fonctionnelle une sous-fonction particulière d'un appareil. Ils peuvent varier en fréquence d'interrogation, en taux de change et en d'autres paramètres. Supposons que si l'appareil semble être un adaptateur USB-COM, sa tâche principale est de recevoir des données du bus et de les transférer vers le port (premier point final) et de recevoir des données du port et de les envoyer vers le bus (deuxième). En termes de signification, ces points sont destinés à un flux important de données non structurées. Mais en plus de cela, de temps en temps, l'appareil doit échanger avec l'hôte l'état des lignes de contrôle (toutes sortes de RTS, DTR, etc.) et échanger des paramètres (vitesse, parité). Et ici, de grandes quantités de données ne sont pas attendues. De plus, il est pratique lorsque les informations de service ne sont pas mélangées avec des données. Il s'avère donc qu'il est pratique d'utiliser au moins 3 points de terminaison pour l'adaptateur USB-COM. En pratique, bien sûr, cela se passe de différentes manières ...
Une question tout aussi intéressante est de savoir pourquoi l'appareil reçoit son adresse, car en dehors de cela, vous ne pouvez toujours rien coller sur ce port particulier. Ceci est fait pour simplifier le développement des concentrateurs USB. Ils peuvent être assez "stupides" et simplement diffuser des signaux de l'hôte vers tous les appareils sans se soucier du tri. Et l'appareil lui-même le découvrira, traitera le paquet ou l'ignorera.
Ainsi, l'adresse du périphérique et l'adresse du point de terminaison sont contenues dans les paquets marqueurs. La structure de ces packages est donnée ci-dessous:
le terrain

le terrain	SYNC	addr	point final	CRC	Eop
Bits USB	0-7	0123456	0123	01234	01
bits reçus		0123456	7012	34567

, - ( - PID = SETUP OUT) (IN) , .

, (-) (Handshake) :

• : , , NAK
• -: SETUP OUT, , IN — ,
• . , , ,

« — » . PID', , . «PID» . usbCurrentTok. PID' (DATA0, DATA1) , . , ? : , ( 0 usbCurrentTok ), , . ( SE0) , - , D+, D- . , SYNC, . , , . «» , . .

, . x3, (, , , ).

, USB , , . , , , CRC ( ). , [21]. 0- . , [26]. , CRC, .

9.

, , « », ACK. NAK', ( cnt — ). USB , , SYNC PID. Y, cnt ( ). , — ACK. x3 — 1 , . x3 ( r20) 20.

( SETUP, ), ACK' , , , . , .

, D+, D- ( ), — . XOR , , , , - .

, , , , . , , , . . vusb : txBitloop 2 ([00], [08]). 3 , 6 . , . 1 3 : 171. ( 171, 11 , ), — , . cnt=4:

4 — 171 = -167 = ( ) 89 (+ )
89 — 171 = -82 = ( ) 174 (+ )
174 — 171 = 3. ,
, .

, 3 , 1. 6 , , x4. D+, D- , . .
:

 2D|80|06|00|01|00|00|40|00 69|00|10|00|01|00|00|40|00 

C3 . , , UART . , , IN , . , .

10. NAK

NAK , . , . , - .

, . , , - , . usbRxBuf, . , — , USB_BUFSIZE. usbInputBufOffset, . .

NAK handleData , [22]. (usbRxLen), - . ( — ), usbRxLen, , — usbRxToken, SETUP OUT - . : , , ACK .

. , , - , -, . ? , , , , - .

,

 2D|80|06|00|01|00|00|40|00 

, NAK`, , .

11.

, , . — . , , , , , . . . , USB, usbPoll. — , . — . SETUP , PID CRC, SETUP 5- , 16-. 3 «» . «» PID usbRxToken, CRC , , . usbProcessRx, , .

, , — , SE0. , USB .

. SETUP, . . SETUP usbRequest_t 8 . : ( USB-) , - . , . .
, , , .

12. SETUP'

, , . . usbDriverSetup, . , . , ( , , ) . , : ACK NAK, .

13.

, SETUP + DATAx, DATAx 8 . IN DATAx, . , . , ACK NAK. , . — usbTxBuf, , usbTxLen . low-speed USB 8 ( PID, CRC), usbTxLen 11. PID, , . , 16, , 0x0F, . PID , . IN, , (handshake , ).

:
SETUP + DATAx, ACK NAK . , , usbPoll, , ( PID=DATA1 ( DATA0 DATA1 , , DATA1). CRC . , , - . — 4 . , 3 , 4. , SYNC . « IN NAK?» NAK. , , DATA1 .

, — USBRQ_SET_ADDRESS ( , ). . (drvsdm.S, make SE0). , , , DATA1 , , . , , , , , . , , .

14.

, . , USBRQ_GET_DESCRIPTOR USBRQ_SET_ADDRESS, , . usbDriverDescriptor, . , USBRQ_GET_DESCRIPTOR. , , :

USBDESCR_DEVICE — : USB (1.1 ), , , . .
USBDESCR_CONFIG — , , . .
USBDESCR_STRING — , .
, , USBDESCR_DEVICE, , .

15.

. -, . , - - , , HID, , . Vendor ID Product ID, USB, . , vusb .

, , - . , , , (, ) usbMsgPtr, — len, usbMsgLen. ( ) 18 , 8. , , 3 . - , STALL.

usbDeviceRead. , memcpy_P, , , .

, , , . , , .

, , .

PID' DATA0 DATA1 . PID' , , - .

, DATA0 / DATA1 ( ), , , 3 , . XOR PID', . , , XOR' . PID DATA1, XOR PID , XOR DATA0 .

, , USBDESCR_CONFIG.

16. - !

USBDESCR_CONFIG USBDESCR_DEVICE. ( , ) . , - USB-, , D+, D-.

, : , , . , ( , ). , UTF-16, . USB UTF-8 .

vusb , lsusb . VID, PID , . , VID, PID, — .

, , ( ). SETUP: , , . 0, , — . , , , .
.

17. (HID)

HID — human interface device, , , . HID , . , , , , , . «» . HID ( low-speed 800 ), .

HID , USBDESCR_HID_REPORT. vusb, . , usbDriverSetup ( ) usbFunctionSetup ( ). , SETUP, OUT. , , , usbFunctionWrite.

, usbDeviceRead usbFunctionRead, . , , usbFunctionSetup ( , ) USB_FLG_USE_USER_RW, usbDriverSetup .

— — usbFunctionWrite usbFunctionRead. . — , .

usbDriverSetup.

18.

, , . HID, , , ( udev - ). , , . , , , .
UPD: ramzes2 , HIDAPI

.

19. vusb

vusb , .

drvasm.S - usbdrvasm.S asmcommon.inc, -, , usbdrvasm12.inc — usbdrvasm20.inc.

main.c main.c ( ) usbdrv.c ( vusb)
usbconfig.h ( ), , , usbconfig.h.

Conclusion

vusb, , , . , , . . , , , USB-HID. , , , vusb, , , , .

https://www.obdev.at/products/vusb/index.html ( vusb)
http://microsin.net/programming/arm-working-with-usb/usb-in-a-nutshell-part1.html
.. USB:
https://radiohlam.ru/tag/usb/
http://we.easyelectronics.ru/electro-and-pc/usb-dlya-avr-chast-1-vvodnaya.html
http://usb.fober.net/cat/teoriya/

PS - (, ) ,