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


8

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?


2
Chi hai dovuto uccidere per trovare quei telemetri laser e aveva un amico che avrebbe potuto averne anche alcuni?
Connor Wolf,

@ConnorWolf Hah! Vorrei possederli. È per l'ag (che determina il volume del raccolto), quindi erano disposti a sborsare per l'hardware (i trattori possono costare $ 75k ...), ma non volevano sborsare per il talento di programmazione.
Canisrufus,

Non conosco la dimensione del buffer in Windows, ma sicuramente vuoi verificarlo. Su Linux questi buffer hanno una dimensione di 4kB e, a seconda dei dati che stai inviando e delle chiamate di sistema che usi, un programma può ricevere solo blocchi di dati da 4kB. Se questo è il problema che desideri controllare attentamente quali chiamate di sistema usi per leggere dai buffer.
jippie,

1
Ti suggerisco di cercare di ottenere una connessione seriale diretta: puoi ottenere schede con porta seriale per PC e laptop (nota anche che la maggior parte dei hardbook Panasonic hanno ancora porte seriali di serie). Questo eviterà qualsiasi problema di buffering nell'interfaccia USB-seriale. Windows 7 ha una capacità in tempo reale abbastanza buona, quindi probabilmente non è necessario spostarsi da quello.
Preoccupato di

Solo un commento: il titolo è divertente, ma non aiuta molto a capire il contenuto della domanda: potresti chiarirlo?
clabacchio

Risposte:


6

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.


Per quanto riguarda il sistema operativo: al momento sto usando Windows 7 su un tablet single core. Posso anche usare un laptop e installare quello che voglio.
Canisrufus,

7
Dedicare un microcontrollore alla correlazione dei dati, quindi inoltrarlo a una finestra di Windows per scopi di visualizzazione è anche la mia strada. +1
JustJeff

1
La carta che colleghi probabilmente funzionerebbe, anche se da quanto piene di cazzate SeaLevel sembra altrove, non sono sicuro di fidarmi di loro. Per quel che vale, che fanno menzione che quella PCI-e scheda utilizza un 16C954quad hardware UART IC (presumibilmente ci sono due di loro sulla carta).
Connor Wolf,

1
Davvero, penso che l'unica soluzione adeguata sarebbe chiamarli e chiedere semplicemente di avere problemi di latenza. Ci possono essere cose che possono essere sintonizzate nel loro driver!
Connor Wolf,

2
+1 sulla soluzione STM32F4; la scheda STM32F4-Discovery è comicamente sotto -priced, ha fino a 6 UART, e una porta OTG FS USB. Se non hai familiarità con il design incorporato, troverai abbastanza difficile far funzionare l'USB su di esso; più semplice collegarsi semplicemente attraverso un UART con un cavo FTDI. L'IDE Coocox è gratuito, non ha limiti di dimensione del codice e supporta la scheda Discovery abbastanza bene.
Markt

3

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.


Più facile che costruire un orologio in tempo reale nell'MCU e sincronizzarlo tramite GPS è solo usare una delle periferiche timer / contatore per misurare il numero di cicli tra il messaggio GPS e il messaggio del telemetro e aggiungere le informazioni delta-time a il flusso di dati.
Ben Voigt,

3

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.


1

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.

inserisci qui la descrizione dell'immagine

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!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.