Que puis-je faire pour diminuer la latence de ces ports série qui sont connectés à un PC via un adaptateur série-USB?

Je pense avoir découvert accidentellement un besoin dans ma vie de systèmes embarqués. Qui est super! Et un peu effrayant. Et j'ai besoin d'aide.

Contexte : J'ai été embauché pour créer une application graphique qui prend des numérisations de deux SICK LMS-291 et les intègre avec un GPS d'une précision inférieure à un pouce, afin que vous sachiez où chaque balayage s'est produit. En tant que programmeur web naïf que je suis, j'ai compris que le timing serait important, mais je ne savais pas que ce serait aussi difficile! Si vous ne savez pas quand chaque point GPS et chaque scan ont eu lieu, vous ne pouvez pas déterminer où les scans ont lieu. Oops.

Ils avaient spécifié Windows 7 comme plate-forme, et acheté un boîtier SeaLevel RS422 vers USB pour brancher les capteurs et le GPS, et en peu de temps j'ai découvert ma folie. Quelque part entre les capteurs et mon programme informatique, quelque chose empêchait les analyses d'arriver en temps opportun. Le LMS émet 75 scans par seconde, soit à 13,32 ms / scan. Mon programme ne les reçoit pas en temps opportun. Il les obtient toutes les 100 millisecondes environ, par groupes de 7 ou 8 ou 10 ou quelque chose. Parfois, il n'y a pas assez d'analyses ou elles sont mutilées. Soit cet adaptateur SeaPort n'envoie que dix fois par seconde (est-ce possible? Je ne sais pas comment fonctionne l'USB) soit Windows ne vérifie pas le tampon (il doit y avoir un tampon quelque part, non?) Presque assez souvent.

Aujourd'hui : cela conduit à des inexactitudes avec lesquelles le client est fondamentalement d'accord. Je ne le suis pas, cependant, et comme j'ai la chance de faire un travail similaire pour le client (en intégrant plus d'entrées de capteurs!), Je voudrais comprendre comment le faire correctement, par exemple compte tenu de la précision du GPS , être en mesure de donner des garanties sur la précision et l'exactitude des emplacements de numérisation.

A quoi cela ressemble-t-il? J'ai besoin d'une interface utilisateur et de pouvoir vérifier les entrées de ces trois appareils toutes les 13,32 millisecondes. Si j'utilisais FreeRTOS avec, disons, Nano-X pour l'interface graphique, exécuté sur un ordinateur portable qu'ils fournissent, cela ressemblerait-il à une solution sensée? Est-il possible que l'adaptateur RS-422 vers USB soit à l'origine de ces retards, et l'utilisation de Windows est en fait très bien à cet effet?

Le problème est presque certainement lié à la mise en mémoire tampon USB liée au convertisseur USB-RS422. L'USB a une latence variable et assez élevée.

La solution la plus simple serait simplement une meilleure interface RS422, idéalement basée sur PCI / PCI-e. Cela résoudrait les problèmes de latence.

Vous pouvez également être en mesure de modifier le taux d'interrogation USB, bien que cela dépende assez du système d'exploitation hôte (sur quelle plate-forme êtes-vous?).

Pour ce que ça vaut, j'ai regardé sur le site Web du système de niveau marin, et il est MASSIVEMENT infecté par des conneries marketing. Ils dépensent littéralement comme 10 pages et plusieurs livres blancs pour dire "nous utilisons un concentrateur USB en interne, plutôt que de faire du multiplexage MCU".

Hé SeaLevel! C'est aussi ce que fait l'interface série USB à 4 ports bon marché de 50 $ que j'ai achetée sur e-bay en Chine! Vous n'êtes pas spécial, même si vous écrivez une demi-douzaine de livres blancs insipides en essayant de donner l'impression que vous êtes!

Avez-vous essayé de forcer ces choses à utiliser des pilotes FTDI? Je mettrais de l'argent dessus, ils utilisent simplement le FTDI FT232 standard ou un similaire. Pouvez-vous ouvrir la boîte de l'un d'eux et prendre des photos?

Si vous voulez vraiment faire tourner votre propre matériel, pour des occasions amusantes ou éducatives, je vous suggère fortement de ne pas essayer de tout faire dans le matériel. Comme vous devez simplement établir une corrélation temporelle entre les trois signaux, tout ce dont vous avez vraiment besoin est quelque chose qui puisse écouter sur trois lignes série (deux RS422, une RS232 (le GPS)), horodater les données et les transmettre à l'ordinateur principal. .

Une fois les données horodatées, vous êtes libre d'avoir toute la latence du tampon que vous souhaitez, car vous pouvez toujours simplement regarder les horodatages.

De manière réaliste, si vous n'avez pas de base matérielle, concevoir quelque chose avec suffisamment de crunch pour dessiner une belle interface graphique est tout à fait une entreprise.

Personnellement, je lancerais probablement un MCU ARM assez gros sur le problème de mise en mémoire tampon et j'en aurais fini. Malgré le fait qu'il s'agit d'un Arduino, l' Arduino Due a beaucoup de SRAM et est plus que suffisamment rapide pour ce dont vous avez besoin (et il y a beaucoup de support, ce qui est toujours agréable).
Alternativement, la série STM32 a des performances similaires et est plus destinée aux utilisateurs "avancés" (lire, il y a moins d'exemples ou pas d'exemples à référencer). ST fabrique également de nombreuses planches d'évaluation très agréables et extrêmement peu coûteuses .

Avec le Due, vous obtenez un port USB natif, pour lequel vous pouvez rouler votre propre pilote CDC si vous le souhaitez. Certaines cartes STM32 ont également un port USB natif.

Si je comprends bien la question, cela revient à prendre les messages de temps / lieu du GPS sur une ligne série et à corréler les messages de données de distance reçus sur d'autres lignes série. Idéalement, les messages du télémètre auraient leur propre horodatage, et si vous pouviez synchroniser toutes les horloges, vous seriez en mesure de localiser l'emplacement où la plage a été prise en interpolant l'horodatage de la plage entre les deux messages GPS avec le horodatages correspondants les plus proches. Mais bien sûr, vous n'en avez pas.

Quelques solutions me viennent à l'esprit, tout au long de l'utilisation d'un microcontrôleur pour effectuer la corrélation des données en temps réel et du pompage de la sortie de celles-ci dans le PPC à des fins d'affichage. Fondamentalement, le microcontrôleur est là pour gérer les problèmes de synchronisation serrés.

Donc, pour une solution plus simple, tout ce dont vous avez besoin est un moyen de collecter tous les messages des différentes lignes série et de les combiner en un seul flux, dans l'ordre dans lequel ils ont été reçus, et de les pomper dans le PC. Vous pouvez en déduire que tout message de télémètre entre deux messages GPS s'est produit entre ces deux messages.

Cela vous donne bien sûr un degré d'incertitude, en fonction de la fréquence des messages GPS. Le compromis est que lorsque vous augmentez la fréquence des messages GPS (pour obtenir une corrélation plus précise), vous augmentez les demandes sur le microcontrôleur et les demandes sur la liaison série vers le PC. À l'extrême, la liaison série est saturée de messages GPS avec un message de portée occasionnelle. De toute évidence, la plupart de ces messages GPS ne sont pas nécessaires. L'avantage de cette solution est que le micro n'a que très peu à faire, du point de vue logiciel. Vous pouvez tout faire dans une simple boucle de langage d'assemblage, aucun système d'exploitation requis.

Pour une solution plus complexe, vous pouvez former une horloge locale dans le micro et utiliser le GPS pour synchroniser cette horloge, de sorte que lorsque vous obtenez un message de portée, vous pouvez obtenir un horodatage à l'aide de l'horloge du micro. En utilisant un micro avec une base de temps cristalline, vous pourriez probablement vous en tirer avec des messages GPS à 1 Hz et obtenir encore bien mieux que des millisecondes de précision sur les messages de portée. Une personne compétente en systèmes embarqués pourrait probablement également retirer celui-ci en assembleur sur un micro bas de gamme, mais vous avez mentionné que vous débutiez. Vous pourriez regarder un micro plus puissant qui peut exécuter linux et trouver probablement une solution préexistante pour synchroniser l'horloge linux avec le GPS.

Ce que je ferais probablement, c'est de multiplexer les données série dans un nouveau flux de données série à un taux plus élevé, avec un entrelacement statique. Envoyez ensuite le flux de données via USB-UART à l'ordinateur. De cette façon, vous sauriez que le premier octet provient du périphérique 1, le deuxième octet du périphérique 2, le troisième octet du périphérique 3 et dans ce cas un quatrième octet en tant que CRC ou numéro de séquence. Ajoutez quelques octets au début du marqueur de trame pour synchroniser le flux de données, remplissez les octets si aucune donnée n'est disponible et vous avez terminé. Vous ne connaissez peut-être pas le temps absolu, mais vous savez que le temps relatif entre les différents blocs de données.

J'irais également avec un microcontrôleur pour recevoir les données RS, les horodater et les transmettre au PC. Vous ne pouvez pas faire de travail critique de synchronisation des E / S avec un PC Windows (sauf avec une carte son, peut-être), car le logiciel et les pilotes changent tout le temps car les pilotes sont mis à jour derrière votre dos.

Mais la première chose que je ferais est d'obtenir un analyseur logique USB, vous pouvez en acheter un pour moins de 100 USD, récupérer quelques messages du récepteur GPS et vérifier exactement quand chaque octet est reçu. Utilisez ces informations pour essayer / calculer exactement la précision de la synchronisation des données en premier lieu: par exemple exactement quoi et quand la boîte GPS transmet. Ensuite, vous pouvez déterminer quelle précision est réalisable et combien d'efforts vous seriez prêt à consentir pour atteindre un certain niveau de précision.

Ci-dessus, une photo d'un analyseur logique USB (Saleae?).

[Modifier] Haha, utiliser la carte son pourrait être une drôle de façon de la faire fonctionner; vous pouvez connecter les données UART à l'entrée de la carte son (via certaines résistances et condensateurs) et écrire un logiciel pour détecter chaque front dans le flux série, vous donnant une belle précision de synchronisation!. Ok, je ne suggère pas vraiment ça sérieusement, juste pour quelques rires!