Accès aux pneus Redd sur les ponts FTDI

Nous avons terminé un grand bloc théorique montrant comment construire un sous-système FPGA pour le complexe Redd; comment organiser la communication entre le FPGA et le processeur central du complexe; combien il est facile d'enregistrer des flux de données à haute vitesse dans la RAM, qui est directement connectée au FPGA, pour leur transfert ultérieur tranquillement vers le processeur central (ou vice versa, pour placer les données dans cette RAM pour une sortie rapide ultérieure sur le canal). Nous avons examiné les techniques de traçage du processeur Nios II. Nous sommes en mesure d'optimiser les performances du système de processeur basé sur Nios II afin que le travail se déroule le plus efficacement possible. En général, nous avons étudié toutes les théories minimales nécessaires, et il serait temps de passer à la pratique en concevant un appareil pas très complexe, mais pratiquement utile ... Mais il y a un MAIS.

D'après les commentaires sur les articles, j'ai remarqué que certains lecteurs croient que Redd et FPGA sont comme Lénine et le Parti. Qu'elles sont inextricablement liées. En fait, ce n'est pas du tout le cas. Je voulais juste entamer une conversation sur le complexe Redd avec quelque chose d'intéressant, mais quoi de plus intéressant que le FPGA? Eh bien, et commencer une conversation, interrompre d'un coup d'œil est stupide. Et enfin, le gros bloc logique est terminé. Et pour montrer que les FPGA sont loin de l'ensemble de Redd, je propose de faire environ trois articles sur des choses qui ne leur sont pas liées. Eh bien, et après avoir terminé ce bloc, allez déjà à la pratique FPGA.

Présentation

La chose la plus étonnante est que dès que j'ai décidé de faire une digression sur d'autres sujets, les bons patrons m'ont lancé dans une bataille difficile sur un projet où le travail se poursuit avec le langage VHDL et Xilinx FPGA. Premièrement, c'est pourquoi pendant longtemps je n'ai pas pris de stylo en général, et deuxièmement, il est clair que la préparation d'articles pratiques nécessite un grand nombre d'expériences. Il est quelque peu difficile de gérer simultanément VHDL / Verilog et Xilinx / Altera. Il faudrait donc de toute façon faire une pause dans les histoires sur les FPGA.

Alors. Dans le premier article de la série, nous avons déjà examiné le schéma structurel du complexe de Redd. Faisons-le encore une fois.



Dans l'article d'aujourd'hui, les experts Linux ne trouveront probablement pas beaucoup d'informations précieuses, mais cela vaut la peine de passer en revue les images superficiellement. Ceux qui, comme moi, sont habitués à travailler à partir de Windows, trouveront une liste de techniques toutes faites qui vous permettront de travailler avec le complexe. En général, cet article apportera les compétences de ceux-ci et d'autres groupes de lecteurs à un dénominateur commun.

Blocs UART (ports série)

Dans le diagramme, nous voyons le contrôleur FT4232 qui implémente 4 ports série (UART):



Mais si vous parlez un peu plus globalement, le complexe Redd n'a pas quatre, mais six ports série. Je viens de mentionner que quatre ont des niveaux CMOS et deux autres sont soudés sur la carte mère, car le complexe est basé sur un PC ordinaire.



En conséquence, ils ont des niveaux - RS232 (plus ou moins 12 volts). Ports RS232 - tout est clair avec eux, ils sont affichés sous la forme de deux connecteurs DB-9 standard,



et où chercher des lignes avec des niveaux CMOS? En général - sur un connecteur commun. Son brochage est indiqué sur le schéma électrique. Il existe, entre autres, des contacts correspondant à l'UART.



Extérieurement, ce connecteur se présente comme suit:



Comment l'utiliser dépend de la tâche. Vous pouvez créer un faisceau pour connecter chaque appareil. Cette approche est utile si quelqu'un utilise le complexe Redd pour tester des appareils du même type fabriqués périodiquement. Mais le but principal du complexe est toujours de déboguer l'équipement en cours de développement. Et dans ce cas, il est plus facile de s'y connecter de manière temporaire. Ce motif temporaire est visible sur les économiseurs d'écran pour tous les articles: les fils Aruino sont insérés directement dans le connecteur. Bien sûr, compter les contacts est toujours un plaisir, et s'ils s'envolent accidentellement, il est si difficile de rétablir la commutation qu'il est plus facile de tout reconnecter à partir de zéro; par conséquent, pour faciliter la vie, il existe une carte de montage sur laquelle vous pouvez vous connecter en utilisant au moins des connecteurs à deux rangées, au moins avec le même câblage Arduino.

Accès au logiciel UART

Le port série est un élément bien établi et bien standardisé, donc travailler avec lui ne passe pas par certaines bibliothèques FTDI spécifiques, mais par des moyens standard. Voyons à quoi ressemblent ces outils sous Linux.

Noms des ports

À partir d'un certain nombre d'articles et de forums sur le réseau, il s'ensuit que les noms de port fournis par les adaptateurs USB-série sont au format / dev / ttyUSB0, / dev / ttyUSB1, etc. Sous Linux, tous les périphériques peuvent être visualisés en utilisant les mêmes commandes que pour afficher les répertoires ordinaires (en fait, les périphériques sont les mêmes fichiers). Voyons quels sont les noms dans notre système. Nous donnons la commande:
ls / dev /



Les noms qui nous intéressent sont surlignés en rouge. Quelque chose d'entre eux. Quel port correspond à quoi? Ceux qui connaissent bien Linux connaissent des milliers de sorts pour toutes les occasions. Mais pour ceux qui travaillaient encore avec Windows 3.1 (enfin, en parallèle avec la vieille dame très nerveuse RT-11), c'est toujours difficile à retenir, avec l'âge, le nouveau est plus difficile à retenir. Par conséquent, il est plus facile de tout trouver à chaque fois, en utilisant des méthodes simples. Et j'ai mis en évidence l'entrée de ce chemin simple avec un cadre vert. Sous-répertoire conditionnel série. Nous regardons maintenant l'espace de noms / dev / . Et voyons l'espace / dev / serial :



Super! Nous plongons dans la hiérarchie, regardons l'espace / dev / serial / by-id . En regardant juste en avant, je dirai que pour un affichage correct, vous devez utiliser la commande ls avec le commutateur –l (merci à mon patron pour la clarification). Autrement dit, nous donnons la commande:
ls –l / dev / serial / by-id



D'une part, tout va bien. Nous savons maintenant quels noms dans l'espace / dev / ttyUSBX correspondent à quel périphérique. En particulier, les ports organisés par le pont FT4232 (Quad) ont des noms de ttyUSB3 à ttyUSB6 . Mais d'un autre côté, en considérant ce site, je me suis rendu compte qu'à Paris, dans la chambre des poids et mesures, il doit nécessairement y avoir une pièce dans laquelle le standard du bordel est placé ... Parce qu'en quelque sorte il faut pouvoir mesurer sa valeur. Eh bien, disons que le manque de ports / dev / ttyUSB0 et / dev / ttyUSB1 peut être facilement expliqué. Mais comment expliquer que les ports «natifs» basés sur la progéniture du pont FTDI installé sont numérotés parmi les trois premiers, et le contrôleur Prolific tiers, inséré pour un projet spécifique, a pris le port numéro 2? Comment travailler dans un tel environnement? Demain, quelqu'un va brancher un autre contrôleur dans le complexe (car le complexe permet à différents groupes de développeurs de travailler simultanément avec différents équipements), et les ports se déplacent à nouveau. Quels ports devons-nous enregistrer dans le fichier de configuration pour une application qui fonctionne?

Il s'avère que tout n'est pas si mal. Premièrement, le nom jaune / dev / ttyUSB3 et le nom bleu / dev / serial / by-id / usb-FTDI_Quad_RS232-HS-if00-port0 sont deux alias du même périphérique. Et la deuxième option peut également être présentée comme le nom du port, mais elle est déjà plus permanente que la première. Certes, dans ce cas, tout est quelque peu mauvais. Un contrôleur externe basé sur FT4232 peut être branché sur le complexe, et il sera déjà nécessaire de gérer leur numérotation. Et voici «en second lieu» vient à notre aide. À savoir, une autre convention de dénomination alternative. Nous nous souvenons que le répertoire / dev / serial contenait non seulement le sous- répertoire / by-id , mais aussi le sous- répertoire / by-path . Nous vérifions son contenu (il est situé en bas de la figure suivante, sous une ligne rouge).



Tout ici est lié à l'architecture physique. Et j'ai déjà dit à plusieurs reprises que tous les contrôleurs à l'intérieur du complexe sont soudés aux cartes, donc la hiérarchie interne ne changera pas. Ainsi, le nom /dev/serial/by-path/pci-0000:00:15.0-usb-0:6.5:1.0-port0 sera le plus difficile.

Au total, nous avons la façon suivante de rechercher le nom du port (cela doit être fait une fois, les résultats de votre instance du complexe peuvent être mis dans le tableau et utilisés en permanence):

1. Exécutez la commande ls –l / dev / serial / by-id .
2. Exécutez la commande ls –l / dev / serial / by-path .
3. À partir des résultats du point 1, recherchez le nom du port correspondant au port requis du pont requis. Recherchez le même nom de port dans les résultats du paragraphe 2. Prenez le nom physique correspondant à ce paragraphe.

Pour les ports desservis par le contrôleur sur la carte mère, tout est un peu plus compliqué. Ici, vous ne pouvez pas faire le chemin à partir de la commande la plus simple " ls / dev ", mais vous devez vous souvenir de quelque chose (enfin, ou du moins, rappelez-vous que vous pouvez contacter ici pour obtenir de l'aide). Partout, il est indiqué que les noms de port typiques sont ttyS0-ttyS3 . La question demeure, sur quels noms sont les vrais ports de notre système? J'ai trouvé le sort suivant répondant à cette question:
ls / sys / class / tty / * / device / driver

Voici la réponse du système:



Il s'avère que nous devons utiliser les noms / dev / ttyS2 et / dev / ttyS3 . Pourquoi - je ne sais pas. Mais une chose plaît: ici aucun changement spécial n'est prévu, donc ces constantes peuvent être mémorisées et utilisées sans crainte de changer.

Développement de code

Lors du développement, vous devez utiliser le merveilleux Guide de programmation série pour les systèmes d'exploitation POSIX (le premier lien direct que vous obtenez est https://www.cmrr.umn.edu/~strupp/serial.html , mais personne ne sait combien de temps il durera). Il est particulièrement important qu'il indique comment travailler avec un ensemble complet de signaux, car les ports du complexe sont entièrement implémentés. Certes, nous n'utiliserons aujourd'hui que les lignes Tx et Rx.

Habituellement, je donne les résultats de la forme d'onde, mais maintenant il s'avère que je suis dans des conditions presque réelles: le complexe est situé là où mes mains ne peuvent pas atteindre, donc je ne peux pas connecter la sonde de l'oscilloscope. Pour voir au moins un résultat, à ma demande, mes collègues ont ajouté quelques publications au complexe selon le schéma classique suivant:



Essayons de transférer d'un port à un autre. Dans notre cas, les ports /dev/serial/by-path/pci-0000:00:15.0-usb-0:6.5:1.2-port0 et /dev/serial/by-path/pci-0000:00:15.0- sont connectés usb-0: 6.5: 1.3-port0 .

Nous avons déjà discuté de la façon dont les programmes du processeur central Redd sont écrits dans l'un des articles précédents , donc aujourd'hui nous nous limiterons au texte du programme écrit sous l'impression du document Serial Programming Guide for POSIX Operating Systems . En fait, le principal point intéressant est de passer de la stratégie de réception à une lecture non bloquante, le reste est trivial. Néanmoins, compte tenu du désordre dans les exemples sur le réseau à ce sujet, il est préférable d'avoir un échantillon trivial à portée de main (il sera montré plus tard que même un exemple basé sur ce merveilleux document n'a pas fonctionné à 100%, le code ci-dessous diffère des canons qui y sont décrits en une seule ligne, mais plus sur celle ci-dessous).


Run - nous obtenons le résultat prévu:

 hello from ReddUARTTest! 14 read operations Read Data: FF FE FD FB 

On peut voir que 4 octets ont pris 14 tentatives, c'est-à-dire que la lecture n'était pas bloquante. Parfois, le système renvoyait un état «aucune nouvelle donnée» et le programme s'endormait pendant une milliseconde.

En général, tout va bien, mais sans oscilloscope, je ne peux pas être sûr que deux ports basés sur la même puce définissent vraiment la vitesse. J'ai déjà sauté sur le fait que la vitesse était la même (pour cela il avait un contrôleur), mais pas celle que j'avais commandée. Vérifions au moins en quelque sorte qu'il est au moins contrôlé. Pour ce faire, je vais régler la vitesse du port de réception pour doubler celle du port de transmission. Et connaissant la physique du processus de transfert de données, vous pouvez prédire comment ces données sont déformées lors de la réception. Regardons le transfert de l'octet 0xff sous forme graphique. S - bit de départ (il y a toujours zéro), P - bit d'arrêt (il y en a toujours un), 0-7 - bits de données (pour la constante 0xFF - toutes les unités).



Maintenant, superposons cette vue avec une vue de la façon dont tout sera vu par un récepteur fonctionnant à deux fois la vitesse:



Super. La valeur "1111 1110" doit être acceptée (les données avancent le bit le moins significatif), c'est-à-dire 0xFE. La seconde moitié de la valeur transmise n'affecte pas la réception, car les unités correspondent au silence dans la ligne. Autrement dit, nous avons transmis un octet, un octet viendra également.

Nous allons construire le même graphique pour la vérification, qui correspondra à la valeur 0xFE transmise:



Attendez-vous à la valeur "1111 1000" ou 0xF8. Eh bien, vérifions à quoi s'attendre avec la valeur passée 0xFD:



Nous obtenons la valeur 0xE6. Eh bien, pour la valeur transmise 0xFB, nous obtenons le 0x9E reçu (vous pouvez tracer le graphique et voir par vous-même). Super! Nous modifions une seule ligne dans l'application de test, en remplaçant la vitesse de 9600 par 19200:

  int fd2 = OpenUART("/dev/serial/by-path/pci-0000:00:15.0-usb-0:6.5:1.2-port0", 19200); 

Nous commençons et obtenons ce résultat de travail:

 hello from ReddUARTTest! 9 read operations Read Data: FE F8 E6 9E 

Soit dit en passant, je n'ai pas effectué en vain cette vérification. Au début, j'ai utilisé d'autres fonctions de réglage de la vitesse (paire cfsetispeed / cfsetospeed), et elles n'ont pas fonctionné! Grâce à ce test, le problème a été identifié et résolu en temps opportun. Lorsque vous travaillez avec un équipement, vous ne pouvez jamais faire confiance à l'intuition. Tout doit être vérifié!

Gestion de la ligne électrique 220 volts

En général, les lignes électriques 220 volts ne sont pas liées au sujet de l'article (ponts FTDI), mais elles sont liées au sujet de cette section (ports série). Jetons un coup d'œil à eux.



Lorsque nous avons répertorié les ports, nous avons vu ce nom:



Il s'agit d'un port série virtuel. Il est tellement virtuel qu'il n'a pas d'importance quels paramètres il a (vitesse du port, nombre de bits, format de parité, etc.). Quels que soient les paramètres définis, il sera toujours en mesure de gérer parfaitement les commandes. Et ce sont ces équipes qui contrôlent les prises de courant sur le complexe.



Lors du développement du système de commande, il a été décidé d'abandonner les interfaces de commande complexes. La gestion prend un octet, sans encadrer les chaînes et autres fioritures, bien que l'octet soit textuel (afin qu'il puisse être facilement transféré du terminal lors du débogage). Cette concision s'explique facilement: l'interface de chaîne vous permet de gérer les interférences dans un canal UART non sécurisé. Mais dans notre cas, physiquement, le travail passe par le canal USB, qui est protégé par des codes de contrôle cycliques. Le traitement du flux de retour nécessite d'écrire du code supplémentaire ou de vider constamment les tampons, ce qui n'est pas toujours pratique. C'est pourquoi il n'y a pas de repères pour les chaînes, il n'y a pas de réponses. On pense que le canal est stable. Si vous voulez une réponse, vous pouvez la demander explicitement. Autrement dit, les performances du bloc peuvent toujours être facilement vérifiées en envoyant un octet supplémentaire après la commande.

Considérez les commandes qui peuvent être envoyées:

La commande '?' (point d'interrogation) est le seul qui renvoie une réponse. En réponse, 3 octets viennent toujours, chacun correspondant à l'état de l'une des prises. En fait, les états correspondent aux commandes. Par exemple, 'abc' - les trois prises sont maintenant fermées, 'Abc' - la première est allumée, la deuxième et la troisième sont éteintes, etc.

Pour les expériences avec ce sous-système, je suggère de ne pas écrire un programme spécial (il n'est pas différent de celui donné précédemment, seules les données envoyées aux ports seront différentes), mais d'utiliser les outils du système d'exploitation et de jouer de manière interactive avec les sockets.

Après de nombreuses expériences avec le suivi du port via la commande cat et l'envoi de commandes dans une fenêtre parallèle en utilisant le programme echo, je me suis rendu compte que pour une raison quelconque je ne peux pas obtenir de résultats dans une paire de terminaux ssh à base de mastic (même en jouant avec les ports avec lesquels seuls qu'il a parfaitement expérimenté avec son programme). Par conséquent, j'ai dû installer le programme minicom standard. Permettez-moi de vous rappeler la commande d'installation:
sudo apt-get minicom

Ensuite, exécutez-le avec la commande:
minicom –D / dev / ttyACM0

Le nom du port est court, car avec des expériences manuelles, il est plus facile d'entrer. Dans le travail logiciel, comme toujours, il est préférable d'utiliser un nom lié à la hiérarchie matérielle. Encore une fois, je note que je ne configure aucun autre paramètre de port car il est virtuel. Cela fonctionnera avec tous les paramètres.

Ensuite, nous appuyons sur le point d'interrogation dans le terminal et instantanément (sans saut de ligne) nous obtenons une réponse



Cela signifie que toutes les prises sont actuellement désactivées. Disons que nous voulons activer la deuxième prise. Appuyez sur la majuscule «B». Il n'y a aucune réaction à l'écran. Appuyez sur "?" Encore une fois, nous obtenons une nouvelle ligne avec la réponse:



Tout fonctionne. N'oubliez pas de couper 220 volts (commande 'b'). Vous pouvez quitter le terminal en appuyant successivement sur ctrl + A, puis sur X. L'expérience est terminée.

Pneus SPI et I ² C

Les bus SPI (qui peuvent également fonctionner en mode Quad-SPI) et I ² C sont implémentés en combinaison avec des ponts universels. Autrement dit, le complexe a deux ponts, chacun pouvant être allumé soit en mode SPI soit en I ² C. Dans le schéma structurel, la section correspondante ressemble à ceci:



L'essence de l'allumage des bus finaux est visible sur le schéma électrique. Considérez un seul des deux contrôleurs:



Ainsi, les bus SPI et I ² C ne se croisent en aucune façon. Les restrictions à leur utilisation conjointe ne sont déterminées que par les restrictions imposées par FTDI dans le contrôleur FT4222H. Malheureusement, la documentation indique qu'une seule interface peut être active à la fois:



Comment gérer les lignes CFG1_0..CFG1_1 et CFG2_0..CFG2_1, nous nous rencontrerons dans le prochain article. Maintenant, nous pensons qu'ils sont tous annulés.

En général, le travail avec le contrôleur est très bien décrit dans le document FT4222H USB2.0 TO QUADSPI / I2C BRIDGE IC , donc nous ne considérerons pas les caractéristiques des modes de fonctionnement des contrôleurs. Tout est très clair à partir du document mentionné.

Quant au support logiciel, sa description se trouve dans le document non moins remarquable AN_329 User Guide For LibFT4222 . Nous avons déjà travaillé deux fois avec le pont FTDI: dans la seconde moitié de cet article et dans la seconde moitié de celui-ci . Par conséquent, en comparant ce document avec ces articles, vous pouvez rapidement le comprendre et commencer à écrire votre propre code. Permettez-moi de vous montrer le code de référence qui envoie des données au bus SPI, sans s'attarder sur les détails de sa mise en œuvre, il semble douloureusement qu'il a déjà été analysé avec FT2232.

Pièces d'autobus SPI

Les développeurs de code pour microcontrôleurs utilisent souvent le bus SPI comme générateur d'une fréquence prédéterminée. En effet, les impulsions générées uniquement par programmation via les lignes GPIO dépendent de nombreux facteurs. Tout d'abord, la ramification, la rotation de la boucle, nécessitent des cycles de processeur. Deuxièmement, les interruptions, le DMA et d'autres facteurs imprévus peuvent interférer avec le processeur. SPI est plus ou moins stable, sachez vous-même réussir à mettre des octets dans le buffer. Une application typique du bloc SPI, qui n'a pas de relation directe avec ce SPI lui-même, est le contrôle des LED RVB, pour lesquelles la précision du réglage de la durée des impulsions est très importante.

Malheureusement, cela n'est pas acceptable pour les ponts FTDI. Le fragment de code ci-dessus générera ces impulsions sur le bus:



Dans ce cas, les règles de fonctionnement SPI ne sont pas violées, du point de vue de ce bus, tout fonctionne correctement. Gardez à l'esprit que les solutions personnalisées habituelles sur les contrôleurs ne fonctionneront pas ici. Certes, le complexe a beaucoup de connecteurs USB gratuits. Tous les blocs non standard peuvent être développés séparément et connectés à eux.

Pièces de pneu I ² C

La seule chose sensée est d'indiquer l'absence de résistances pull-up pour le bus I ² C du côté du complexe. Mais c'est normal: sur le côté de l'appareil de travail, il y a encore un ascenseur. De nos jours, un pull-up peut être à n'importe quelle tension, il est donc logique qu'il soit réglé sur le périphérique cible.

Conclusion

Aujourd'hui, nous avons acquis des compétences pratiques pour travailler avec des pneus mis en œuvre par des ponts FTDI. En général, travailler avec eux est standard, c'est juste que toutes les connaissances sont résumées dans un seul article, afin de ne pas les chercher petit à petit. La prochaine fois, nous considérerons un module qui contrôle des appareils non standard, implémenté sur la base du contrôleur STM32. Dans le schéma structurel, cette section y correspond:



Mais vraiment, tout y est un peu plus intéressant ...