Travailler avec des pneus personnalisés complexes Redd

Dans le dernier article, nous avons commencé à nous familiariser avec la façon dont vous pouvez travailler avec des pneus standard bien connus en utilisant le complexe Redd, après quoi j'ai promis de passer à la façon d'accéder à des pneus plus exotiques. Mais après avoir parlé avec quelques connaissances, j'ai soudain réalisé que tout le monde ne lisait pas l'article écrit sur le complexe Redd en dehors de ce cycle. Et, en conséquence, tout le monde ne sait pas pourquoi ces pneus ont été ajoutés au complexe. Vous pouvez, bien sûr, simplement vous référer à cet article , mais il me semble qu'il serait plus correct de redire sa partie correspondante en référence au thème de ce cycle particulier. Par conséquent, aujourd'hui, nous examinerons non seulement les questions pratiques, mais aussi théoriques concernant les pneus vendus par le complexe Redd.

Partie théorique ennuyeuse

Ce que nous considérerons

Passons brièvement (autant que possible) en revue certaines questions théoriques pour comprendre clairement pourquoi tout se fait dans le complexe Redd d'une manière ou d'une autre. Tout d'abord, la tâche principale du complexe ... Curieusement, dans le cadre de cette série d'articles, je n'ai jamais écrit à ce sujet. Oui, et je n'ai pas l'intention d'écrire. Le fait est que la tâche principale est un accès à distance conjoint au débogage de certains matériels (des microcontrôleurs aux énormes systèmes de processeurs multicœurs). Réservation du temps de travail, offrant un accès physique à travers des canaux de moche moyenne (et pas seulement idéale) et d'autres délices. Le débogage peut se faire via JTAG ou via d'autres outils fournis par les environnements de développement. Une grande équipe y travaille, tout y est très intéressant, mais je n'aime pas la bureaucratie, donc je ne veux pas écrire sur ces sujets. Peut-être qu'à l'avenir, quelqu'un d'autre comblera cette lacune ... En attendant, j'écris sur les outils auxiliaires du complexe.

Oui, oui, tout ce que je décris depuis plus de six mois n'est que des choses conçues pour aider les développeurs.

Pourquoi dans le complexe Redd, des pneus standard sont mis en œuvre

Très souvent, vous devez développer du matériel sans y avoir accès vous-même. Regardons un exemple spécifique d'un projet qui a de bons liens. Voici, par exemple, mes hélicoptères préférés. Nous sommes ici et les hélicoptères sont en Suède. De plus, nous avons ordonné le développement en hiver, lorsque les hélicoptères ne pouvaient physiquement pas remplir les fonctions que nous leur avons mises en place (à savoir, fertiliser le sol dans les forêts: le sol était à l'époque sous des congères). Il s'avère que les appareils installés dans l'hélicoptère doivent être émulés pendant le débogage et le vol - virtuellement.

Mais c'est du débogage. Lors du test d'un projet, l'émulation est la seule option. Le testeur doit tout vérifier dans le nombre maximum de modes, en triant différentes combinaisons. De plus, il doit créer des situations avec des conditions critiques et d'urgence (un tel travail destructeur pour les testeurs). Comment le faire sur du vrai matériel? Uniquement sur les émulateurs.

Comment se passe la communication avec les appareils modernes? Habituellement - via des bus standard, car les développeurs d'appareils ont tendance à se connecter via quelque chose que les consommateurs connaissent déjà. C'est juste Redd et agira comme un émulateur de nombreux appareils. Ses bus sont connectés au bloc développé. Et l'appareil sera sûr de fonctionner avec un équipement réel, ne sachant pas que de l'autre côté des pneus n'est pas un tas de fer, mais le complexe Redd, sur lequel tournent un certain nombre d'émulateurs.

Lorsque vous travaillez avec un équipement réel, les pneus peuvent agir comme des analyseurs, enregistrant le travail avec du matériel réel pour analyser les vols en cas de problèmes.

En général, il devrait y avoir autant de pneus que possible et leur ensemble aussi varié que possible. Cependant, dans tout ce dont vous avez besoin pour connaître la mesure. Eh bien, ne serait-ce que parce que chaque bus coûte de l'argent et prend de la place dans le boîtier et également sur le connecteur. Voyons maintenant quelles stratégies sont les mieux utilisées pour contrôler ces bus par programmation.

Qui dirigera le développement du code pour Redd

Dans les entreprises modernes, Sa Majesté l'heure de l'homme est au premier plan. Le fait est que c'est une ressource très coûteuse à bien des égards (argent, temps de développement, disponibilité d'un spécialiste à ce moment particulier pour cela et d'autres tâches de l'entreprise, etc.), donc si la direction peut économiser des heures, elle le fera. S'il est possible de ne pas ajouter de développeurs à l'équipe, ils ne seront pas ajoutés. S'il est possible de tout faire en moins de temps, ils élimineront les développeurs afin qu'ils puissent le faire en moins de temps.

Il en résulte qu'il est peu probable qu'ils confient à des spécialistes individuels l'écriture d'émulateurs. Et s'ils le font, ils seront des programmeurs ordinaires travaillant dans la même entreprise.

Pourquoi j'écris ça. Dans certains articles, il est considéré comme chic lorsque certains langages spécialisés sont utilisés pour les tâches d'entretien des pneus non standard. J'ai eu la chance de travailler avec quelque chose comme ça. Permettez-moi de décrire mes impressions sur l'exemple de choses qui ont jamais été publiées. Ici, par exemple, https://www.astrosoft.ru/about/clients/bvg-group/case-959/ . De plus, le langage GOST est récemment sorti même GOST. Mon opinion est la suivante: ce qui était nécessaire à la fin des années 70 - au début des années 80, puis absolument pas nécessaire à la fin du premier quart du XXIe siècle. Voici un merveilleux article de Konstantin Chizhov, dans lequel la chose la plus importante de cette langue (groupes de contact) est parfaitement et presque gratuitement mise en œuvre grâce à la métaprogrammation en C ++ http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikrokontrollerov-na- si.html . Cet article vérifie tout pour AVR. J'ai fait une excellente vérification de l'option de bibliothèque pour Cortex M, les résultats sont également incroyables. Les optimiseurs emballent tout de manière à ce que le développement direct dans l'assembleur ne donne aucun gain. Et cela s'applique non seulement aux groupes de contact, mais en général à tous les pilotes de mcucpp. Il est seulement dommage que les autorités n'aient pas autorisé cette idéologie dans le MAX RTOS, donc les résultats de la recherche ne sont pas entrés dans la publication. Mais à la maison, j'utilise uniquement cette bibliothèque.

Toutes les autres choses implémentées sur YASTEK sont également parfaitement packagées dans la construction C ++. Mais l'interactivité pour l'opérateur à la jonction des années 70 et 80 ne l'était pas. Certes, ce n'était pas dans les compilateurs d'alors de Pascal, C et d'autres langages. La plupart du temps, les compilateurs étaient par lots et généraient simplement du texte d'assembleur sans aucun outil de débogage. Lors du remake de YASTEC, nous avons ajouté des opérateurs pour la sortie des données à l'écran et même un débogueur interactif, mais de toute façon, ce sont des demi-mesures dans le contexte de ce qui se passe dans les environnements de développement prêts à l'emploi pour les langages de programmation ordinaires. Bref, l'époque où il y avait des raisons techniques de faire disparaître le langage spécial de YASTEK. Aujourd'hui, dans un langage de programmation commun, on peut réaliser le même, et bien plus encore.

Quelqu'un peut dire que ce ne sont pas des experts C ++ qui ont écrit le code, mais des personnalisateurs ordinaires ... C'est comme ça, mais j'ai déjà noté que les programmeurs ordinaires écriront le code pour Redd. La direction n'a aucun sens de garder un spécialiste étroit pour les tâches occasionnelles. Et cela n'a aucun sens pour un spécialiste ordinaire d'apprendre une autre langue.

Et quelles autres caractéristiques expressives cela aura-t-il? Lors du développement d'émulateurs, vous devrez peut-être des choses complètement exotiques. Par exemple, pour l'émulateur GPS en mode interactif, nous contrôlons à l'aide du joystick. Quel langage orienté problème le prend en charge? Et la flexibilité de ces langues est toujours. Enfin, la réutilisation du code dans le YASTEC discuté n'est pas à la hauteur, mais la recherche de solutions toutes faites sur le réseau ... Même dans les langues les plus courantes, ce n'est pas seulement pour trouver un bon exemple, mais aussi exotique.

La même chose s'applique à un tel cas , qui s'est facilement transformé en un tel cas . Dans le cadre de l'automatisation d'entreprise, SIMATIC avec son système de configuration et de programmation avancé est bon, mais pour un petit projet, il a créé plus de problèmes qu'il n'en a résolu, il a donc été remplacé par une solution plus universelle.

Au total, nous concluons que le travail des programmeurs ordinaires dans leurs langages habituels est normal pour Redd. Pour d'autres tâches - cela est discuté, et spécifiquement pour les tâches auxiliaires résolues par le complexe Redd, c'est normal.

Comment mettre en place des pneus

Mais si nous disons que les programmeurs ordinaires utiliseront les pneus dans leurs langages habituels, alors les bibliothèques pour travailler avec ces bus devraient être aussi typiques que possible. En particulier, la phrase a été immédiatement notée: «Et mettons les microcontrôleurs dans le complexe, et les programmeurs écriront tout sur eux.» Cette option nécessite à nouveau des spécialistes de ces contrôleurs. De plus, il nécessite une synchronisation sérieuse entre les sous-systèmes. Il a été décidé que, si possible, le programmeur devait travailler sur le processeur central PC familier. "Mais qu'en est-il des FPGA?", Demandez-vous. Eh bien, oups, tout le monde a probablement remarqué que pour les FPGA, j'ai choisi l'idéologie du «développement minimum sur Verilog, maximum familier aux programmeurs». Là, vous ne pouvez pas le faire plus facilement. Mais nous travaillons dur.

Donc, implémentations de pneus typiques. Avec UART, tout est clair. Avec SPI / I ² C, diverses options ont été envisagées, car il n’existe pas de norme de facto établie pour les PC. Mais il y avait un désir de se passer de l'option d'écrire un ensemble complet: "firmware" du contrôleur, du pilote et des bibliothèques. Je voulais prendre quelque chose de prêt. Néanmoins, jusqu'à la dernière fois, nous avons envisagé l'option avec des microcontrôleurs qui implémentent au niveau USB un débogueur à la fois de Cypress. Le point en a été mis en évidence par les découvertes décrites dans l' article sur le DMA . Il est impossible de garantir la bande passante demandée dans le TOR si tous les bus avec des flux de données précédemment inconnus fonctionnent simultanément. Et s'il est réparti sur plusieurs contrôleurs - nous nous reposons sur la bande passante de l'USB 2.0 FS. Par conséquent, seuls les ponts FTDI. Un pont est une fonction et USB 2.0 HS fournit une bande passante.

Par ailleurs, dans la dernière section, j'ai toujours fait référence au langage C ++ commun. Le fait est qu'à ce stade du voyage de ma vie, c'est mon langage de programmation principal (bien que ce n'ait pas toujours été le cas). Mais les solutions standard, ce sont des solutions standard afin de fonctionner parfaitement dans d'autres langages courants aujourd'hui, que ce soit Python, Java ou autre chose. Par conséquent, si un spécialiste de ces langues est lancé dans la bataille, lui, en utilisant ces langues, fera tout non moins facilement. Telle est la beauté des solutions universelles.

Mais il y a quelques pneus qui sont idiots pour poser des puces FTDI coûteuses. Nous allons parler de la façon dont ils sont mis en œuvre dans le complexe.

Mille petites choses

Pourquoi le complexe Redd a-t-il une carte SD commutée

Un certain nombre d'appareils en cours de développement mettent à jour leur «firmware» à l'aide d'une carte SD. Le plus souvent, le «firmware» est versé sur la carte sous la forme d'un fichier, après quoi l'appareil s'éteint et lorsqu'il est allumé, il détecte le fichier de mise à jour et l'applique. J'ai récemment essayé une nouvelle carte pour l'une de mes imprimantes 3D. Là, le «firmware» de Marlin 2.0, après certaines des commandes M (je ne me souviens pas du code exact), a ouvert le contenu de la SD via le bus USB, afin que je puisse injecter des mises à jour sans trucs. Je me suis connecté via USB, après quoi je savais que je mettais hors / sous tension (comment le faire avec l'aide du complexe Redd, nous avons examiné dans l' article précédent ), donné la commande pour connecter la carte SD à USB, attendu que le disque apparaisse, rempli le «firmware», mis hors / sous tension à nouveau, et attendu . Le firmware a été mis à jour. Mais tout n'est pas si beau. Parfois, une carte SD doit être préparée à l'avance. Soit dit en passant, si vous ajoutez la courbe «firmware» à l'imprimante 3D, l'option idéale décrite ci-dessus ne fonctionnera pas non plus et vous devrez également préparer la carte à l'avance. Et lors du développement, créez un «firmware» qui ne fonctionne pas - quelques bagatelles.

Dans ce cas, le complexe Redd dispose d'une carte SD commutée. Sur le schéma électrique, il est inclus comme suit:



Au début, nous avons essayé de trouver une solution typique qui permettrait de commuter le bus SDIO (pas SPI, à savoir SDIO, les appareils peuvent également fonctionner via cette interface) via FPGA. Il s'est avéré qu'une belle solution n'existe pas. Même les solutions des fabricants de FPGA sont complexes et peu crédibles. Par conséquent, des clés analogiques ont été fournies pour connecter physiquement la carte à un connecteur externe ou à un lecteur dans le cadre de Redd. Par conséquent, l'algorithme de fonctionnement est le suivant: connecté à un lecteur, fichiers préparés à l'aide de Linux OS, connecté au périphérique cible. Nous utilisons là-bas.

Comme travailler avec le système de fichiers n'appartient pas à des choses critiques (nous préparons juste les données, donc aucune vitesse spéciale n'est requise), il a été décidé de faire un lecteur basé sur le microcontrôleur STM32F103. La prise en charge de SDIO complet n'est disponible que dans la version maximale de cette puce. Et puisque ce contrôleur a beaucoup de contacts libres, il a été décidé de faire d'autres fonctions à basse vitesse sur eux. Considérons un fragment d'un schéma de circuit électrique, à partir duquel leur liste sera visible.



En fait, les signaux liés à la commutation SDIO et carte SD sont surlignés en rouge. Nous procédons à l'examen des couleurs de rétro-éclairage restantes.

Lecteur flash SPI

La deuxième technique courante pour mettre à jour le «firmware» des équipements cibles est avec un lecteur flash SPI. De nos jours, ce n'est pas de plus en plus SPI, mais Quad-SPI. Le principe est le même. Rempli les données, puis connecté le lecteur flash à l'appareil et allumé. Le mécanisme Bootstrap «aspire» le firmware dans la RAM au démarrage.

Le même schéma est appliqué ici - avec des commutateurs analogiques:



Eh bien, les lignes liées à l'utilisation d'un lecteur flash ont été mises en évidence en vert.

Relais à semi-conducteurs bas

Périodiquement, la tâche se pose de simuler la pression des boutons sur l'appareil. Une situation typique: les testeurs doivent vérifier le fonctionnement du menu de l'appareil cible. Non, une fois que vous pouvez passer en revue tous les points, mais si les développeurs apportent des modifications? Pour automatiser le processus, il est préférable que les boutons de navigation dans le menu soient créés automatiquement (des captures d'écran peuvent être prises soit par le système d'exploitation sur l'appareil cible, soit en scannant le bus allant à l'écran à l'aide du renifleur vers le FPGA). Eh bien, il existe de nombreuses autres tâches où vous devez simuler par programmation une pression sur un bouton. Pour cela, des relais statiques sont ajoutés au circuit:



... et leurs lignes de contrôle étaient surlignées en bleu.

Configuration des ponts USB-SPI / I ² C

Dans un article précédent, j'ai noté que les ponts FTDI sur lesquels les bus SPI et I ² C sont implémentés ont des jambes de contrôle CFG0 et CFG1. En général, très probablement, personne n'aura besoin de modifier leurs valeurs par défaut (tous des zéros), mais si nécessaire, les lignes qui contrôlent ces signaux quittent également le contrôleur STM32 en question et ont été surlignées en violet.

Réinitialisation du périphérique USB

Au cours du développement du système, il a été décidé que, purement théorique, les appareils pouvaient «geler». Par exemple, les ponts FTDI de la première série avaient la propriété de «geler» avec un «sol» instable. Oui, c'était il y a plus de dix ans. Oui, à l'intérieur du complexe, la terre est extrêmement stable, car le pont est dans le même bâtiment que l'ordinateur. Mais tout d'un coup. En général, dans les TdR était prévue la possibilité de réinitialiser l'un des appareils. Les demandes correspondantes sont générées par le même contrôleur STM32 et surlignées en jaune.

Accès par programmation au contrôleur STM32

Comme vous pouvez le voir, la plupart des appareils décrits ci-dessus ne sont pas standard. Plus précisément, la plupart d'entre eux peuvent être classés comme GPIO, mais il n'y a pas de norme de facto pour cela. La partie la plus difficile des appareils est le lecteur de carte SD. Par conséquent, il a été décidé d'implémenter la fonctionnalité SD Reader sur le contrôleur STM32 (heureusement, l'environnement STM Cube MX vous permet de le faire en n'écrivant que quelques lignes de votre propre code), et d'implémenter le reste des fonctions selon les demandes du fournisseur au périphérique de stockage de masse sous-jacent au lecteur. Mais comme il a été décidé il y a plusieurs articles, les énormes récits ne conviennent pas à la lecture. Par conséquent, les principes d'envoi de commandes au périphérique de stockage de masse à partir de Linux et des exemples d'accès par programmation au périphérique résultant seront examinés la prochaine fois.