Cosa posso fare per ridurre la latenza da queste porte seriali collegate a un PC tramite un adattatore da seriale a USB?

Penso di aver scoperto per caso un'esigenza nella mia vita di sistemi embedded. Che è grandioso! E un po 'spaventoso. E ho bisogno di aiuto.

Contesto : sono stato assunto per creare un'applicazione GUI che prende scansioni da due SICK LMS-291 e le integra con un GPS con precisione inferiore a pollici, in modo da sapere dove è avvenuta ogni scansione. Come programmatore web ingenuo che sono, ho capito che i tempi sarebbero stati importanti, ma non mi ero reso conto che sarebbe stato difficile! Se non sai quando si sono verificati ciascun punto GPS e ciascuna scansione, non puoi capire dove si verificano le scansioni. Ops.

Avevano specificato Windows 7 come piattaforma, oltre a comprare una scatola SeaLevel RS422 su USB per collegare i sensori e il GPS, e in breve tempo ho scoperto la mia follia. A metà strada tra i sensori e il mio programma per computer, qualcosa stava impedendo alle scansioni di arrivare in modo tempestivo. L'LMS emette 75 scansioni al secondo o a 13,32 ms / scan. Il mio programma non li ottiene in modo tempestivo. Li ottiene ogni 100 o circa millisecondi, in gruppi di 7 o 8 o 10 o qualcosa del genere. Inoltre a volte non vengono visualizzate scansioni sufficienti o sono alterate. O questo adattatore SeaPort invia solo dieci volte al secondo (è possibile? Non so come funziona l'USB) o Windows non controlla il buffer (ci deve essere un buffer da qualche parte, giusto?) Abbastanza spesso.

Oggi : questo porta ad alcune imprecisioni con cui il cliente è sostanzialmente d'accordo. Non lo sono, però, e poiché ho la possibilità di fare un lavoro simile per il cliente (integrando più input di sensori!), Mi piacerebbe capire come farlo nel modo giusto, ad es. Data l'accuratezza del GPS , essere in grado di fornire garanzie sulla precisione e l'accuratezza delle posizioni di scansione.

Che aspetto ha? Ho bisogno di un'interfaccia utente e per poter controllare l'input da questi tre dispositivi ogni 13,32 millisecondi. Se usassi FreeRTOS con, diciamo, Nano-X per la GUI, girassi su un laptop che forniscono, sembrerebbe una soluzione sana? È possibile che l'adattatore da RS-422 a USB stia causando questi ritardi e l'utilizzo di Windows in realtà va bene per questo scopo?

Il problema è quasi certamente nel buffering USB relativo al convertitore USB-RS422. USB ha una latenza variabile e abbastanza alta.

La soluzione più semplice sarebbe solo una migliore interfaccia RS422, idealmente basata su PCI / PCI-e. Ciò risolverebbe i problemi di latenza.

Potresti anche essere in grado di modificare la frequenza di polling USB, sebbene ciò dipenda in modo considerevole dal sistema operativo host (su quale piattaforma sei?).

Per quello che vale, ho guardato sul sito web del sistema a livello del mare ed è MASSIVAMENTE infetto da stronzate di marketing. Spendono letteralmente come 10 pagine e più white paper per dire "usiamo un hub USB internamente, piuttosto che fare multiplexing MCU".

Ehi SeaLevel! Questo è ciò che fa anche l'interfaccia seriale USB a 4 porte da $ 50 a buon mercato che ho comprato su e-bay dalla Cina! Non sei speciale, anche se scrivi mezza dozzina di vapidi white paper cercando di far sembrare che tu sia!

Hai provato a forzare queste cose a usare i driver FTDI? Ci metterei dei soldi su di loro, stanno solo usando FTDI FT232 standard o simile. Puoi aprire la scatola su una di esse e scattare foto?

Se vuoi davvero girare il tuo hardware, per opportunità divertenti o educative, ti consiglio vivamente di non provare a fare tutto nell'hardware. Dato che devi semplicemente correlare nel tempo tutti e tre i segnali, tutto ciò di cui hai davvero bisogno è qualcosa che possa ascoltare su tre linee seriali (due RS422, una RS232 (il GPS)), timestamp dei dati e inoltrarli al computer principale .

Una volta che i dati sono timestamp, sei libero di avere tutta la latenza del buffer che desideri, dato che puoi sempre solo guardare i timestamp.

Realisticamente, se non si dispone di una base hardware, progettare qualcosa con sufficiente scricchiolio per disegnare una bella interfaccia grafica è piuttosto un'impresa.

Personalmente, probabilmente avrei lanciato un MCU ARM piuttosto grosso sul problema del buffering, e avrei finito. Nonostante sia un Arduino, Arduino Due ha un sacco di SRAM ed è più che abbastanza veloce per quello che ti serve (e c'è un sacco di supporto, il che è sempre bello).
In alternativa, la serie STM32 ha prestazioni simili ed è più destinata agli utenti "avanzati" (leggi, ci sono meno esempi o nessun esempio a cui fare riferimento). La ST produce anche molte schede eval abbastanza belle ed estremamente economiche .

Con Due, ottieni una porta USB nativa, per la quale puoi rotolare il tuo driver CDC se lo desideri. Alcune delle schede STM32 hanno anche USB nativo.

Se capisco la domanda, a cosa si riduce questo è prendere i messaggi tempo / luogo dal GPS su una linea seriale e correlare i messaggi di dati di portata ricevuti su altre linee seriali. Idealmente, i messaggi del telemetro avrebbero il proprio timestamp e, se si potessero sincronizzare tutti gli orologi, si sarebbe in grado di fissare la posizione in cui è stato effettuato l'intervallo interpolando il timestamp dell'intervallo tra i due messaggi GPS con il timestamp corrispondenti più vicini. Ma ovviamente non ce l'hai.

Vengono in mente un paio di soluzioni, lungo le linee di utilizzo di un microcontrollore per eseguire la correlazione dei dati in tempo reale e pompare l'output di quello nel PPC per scopi di visualizzazione. Fondamentalmente il microcontrollore è lì per affrontare i problemi di temporizzazione.

Quindi, per una soluzione più semplice, tutto ciò di cui hai bisogno è un modo per raccogliere tutti i messaggi dalle diverse linee seriali e combinarli in un singolo flusso, nell'ordine in cui sono stati ricevuti, e pomparli nel PC. È possibile dedurre che qualsiasi messaggio del telemetro tra due messaggi GPS si è verificato a volte tra questi due messaggi.

Questo ti dà un certo grado di incertezza, ovviamente, a seconda della frequenza dei messaggi GPS. Il compromesso è che quando si aumenta la frequenza dei messaggi GPS (per ottenere una correlazione più accurata), si aumentano le richieste sul microcontrollore e le richieste sul collegamento seriale nel PC. Ad un estremo, il collegamento seriale è saturo di messaggi GPS con un messaggio di portata occasionale inserito. Ovviamente la maggior parte di quei messaggi GPS non è necessaria. Il vantaggio di questa soluzione è che il micro ha molto poco da fare, dal punto di vista del software. Potresti fare tutto in un semplice ciclo di linguaggio assembly, senza bisogno di SO.

Per una soluzione più complessa, è possibile formare un orologio locale nel micro, e utilizzare il GPS per sincronizzare che l'orologio, in modo che quando si ottiene un messaggio di gamma, è possibile ottenere un timbro di tempo con l'orologio delle Micro. Usando un micro con una base dei tempi di cristallo, probabilmente potresti cavartela con i messaggi GPS da 1Hz e ottenere comunque molto meglio dei millisecondi di accuratezza impressi sui messaggi di portata. Una persona competente nei sistemi embedded potrebbe probabilmente anche eseguire questa operazione in un assemblatore su un micro di fascia inferiore, ma hai detto che hai appena iniziato. Potresti guardare un micro più potente in grado di eseguire Linux e probabilmente trovare una soluzione preesistente per sincronizzare l'orologio Linux con il GPS.

Quello che probabilmente farei è multiplexare i dati seriali in un nuovo flusso di dati seriali a velocità elevata, con un interleave statico. Quindi alimentare il flusso di dati tramite USB-UART sul computer. In questo modo sapresti che il primo byte proviene dal dispositivo 1, il secondo byte dal dispositivo 2, il terzo byte dal dispositivo 3 e in questo caso un quarto byte come CRC o numero progressivo. Lancia in un paio di byte l'inizio del frame marker per sincronizzare il flusso di dati, riempiendo i byte se non ci sono dati disponibili e il gioco è fatto. Potresti non conoscere il tempo assoluto, ma sai che il tempo relativo tra i vari blocchi di dati.

Andrei anche con un microcontrollore per ricevere i dati RS, timestamp e inoltrarli al PC. Non è possibile eseguire alcun lavoro critico sui tempi di I / O con un PC Windows (tranne forse con una scheda audio, perché) perché il software e i driver cambiano continuamente mentre i driver vengono aggiornati alle spalle.

Ma la prima cosa che vorrei fare è ottenere un analizzatore di logica USB, è possibile acquistarne uno per meno di $ 100, prendere alcuni messaggi dal ricevitore GPS e verificare esattamente quando viene ricevuto ogni byte. Usa queste informazioni per provare / calcolare esattamente la precisione dei tempi dei dati: ad es. Esattamente cosa e quando il GPS box trasmette. Quindi puoi capire quale accuratezza è raggiungibile e quanti sforzi saresti disposto a fare per raggiungere un certo livello di accuratezza.

Sopra, una foto di alcuni analizzatori di logica USB (Saleae?).

[Modifica] Haha, usare la scheda audio potrebbe essere un modo divertente per farlo funzionare davvero; potresti collegare i dati UART all'ingresso della scheda audio (tramite alcuni resistori e condensatori) e scrivere software per rilevare ogni fronte nel flusso seriale, dandoti una straordinaria precisione di temporizzazione !. Ok, non sto davvero suggerendo questo sul serio, solo per alcune risate!