O que posso fazer para diminuir a latência dessas portas seriais conectadas ao PC por meio de um adaptador Serial para USB?

Acho que descobri acidentalmente uma necessidade em minha vida por sistemas embarcados. O que é ótimo! E meio assustador. E eu preciso de ajuda.

Antecedentes : Fui contratado para criar um aplicativo GUI que realiza varreduras de dois SICK LMS-291s e as integra com um GPS de precisão de menos de uma polegada, para que você saiba onde cada varredura ocorreu. Como programador da web ingênuo, soube que o tempo seria importante, mas não percebi que também seria difícil! Se você não souber quando cada ponto de GPS e cada verificação ocorreram, não poderá descobrir onde as verificações ocorrem. Opa

Eles haviam especificado o Windows 7 como plataforma e compraram uma caixa SeaLevel RS422 para USB para conectar os sensores e o GPS e, em pouco tempo, descobri minha loucura. Em algum lugar entre os sensores e meu programa de computador, algo estava impedindo que as digitalizações chegassem em tempo hábil. O LMS distribui 75 varreduras por segundo ou a 13,32 ms / varredura. Meu programa não os obtém em tempo hábil. Ele os obtém a cada 100 milissegundos, em grupos de 7 ou 8 ou 10 ou algo assim. Às vezes, também não são exibidas varreduras suficientes ou são mutiladas. Esse adaptador SeaPort está enviando apenas dez vezes por segundo (isso é possível? Não sei como o USB funciona) ou o Windows não está verificando o buffer (deve haver um buffer em algum lugar, certo?) Quase com bastante frequência.

Dia atual : isso leva a algumas imprecisões com as quais o cliente está basicamente bem. Eu não sou, porém, e como tenho a chance de fazer um trabalho semelhante para o cliente (integrando mais entradas de sensores!), Gostaria de descobrir como fazê-lo corretamente, por exemplo, dada a precisão do GPS , seja capaz de dar garantias sobre a precisão e exatidão dos locais de digitalização.

Como é isso? Eu preciso de uma interface do usuário e poder verificar a entrada desses três dispositivos a cada 13,32 milissegundos. Se eu usasse o FreeRTOS com, digamos, Nano-X para a GUI, executada em um laptop que eles fornecem, isso soaria como uma solução sã? É possível que o adaptador RS-422 para USB esteja causando esses atrasos e o uso do Windows seja adequado para esse fim?

O problema está quase certamente no buffer USB relacionado ao conversor USB-RS422. O USB possui latência variável e razoavelmente alta.

A solução mais fácil seria apenas uma interface RS422 melhor, idealmente baseada em PCI / PCI-e. Isso resolveria os problemas de latência.

Você também pode modificar a taxa de polling USB, embora isso dependa bastante do sistema operacional host (em qual plataforma você está?).

Para o que vale a pena, eu olhei no site do sistema de nível de vedação, e ele está MASSIVAMENTE infectado com besteiras de marketing. Eles literalmente gastam 10 páginas e vários documentos técnicos dizendo "usamos um hub USB internamente, em vez de fazer a multiplexação de MCU".

Hey SeaLevel! É isso que também faz a interface USB-serial de 4 portas e US $ 50 que comprei no e-bay da China! Você não é especial, mesmo se escrever meia dúzia de whitepaps insípidos tentando fazer parecer que é!

Você tentou forçar essas coisas a usar drivers FTDI? Eu colocaria dinheiro nisso, eles estão usando o padrão FTDI FT232 ou similar. Você pode abrir a caixa em uma delas e tirar fotos?

Se você realmente deseja girar seu próprio hardware, por diversão ou por oportunidades educacionais, sugiro que você não tente fazer tudo no hardware. Como você precisa simplesmente correlacionar os três sinais no tempo, tudo o que você realmente precisa é de algo que possa escutar em três linhas seriais (duas RS422, uma RS232 (o GPS)), marcar os dados no tempo e enviá-los para o computador principal .

Uma vez que os dados tenham registro de data e hora, você estará livre para ter toda a latência de buffer que desejar, pois sempre poderá observar os registros de data e hora.

Realisticamente, se você não tem base no hardware, projetar algo com capacidade suficiente para criar uma boa interface gráfica do usuário é bastante difícil.

Pessoalmente, eu provavelmente lançaria um ARM MCU bastante robusto na questão do buffer e acabaria com isso. Apesar de ser um Arduino, o Arduino Due possui bastante SRAM e é mais rápido do que o necessário (e há muito suporte, o que é sempre bom).
Como alternativa, a série STM32 tem desempenho semelhante e é mais voltada para usuários "avançados" (leia, há menos ou nenhum exemplo para referência). A ST também produz muitas placas de avaliação bastante agradáveis ​​e extremamente baratas .

Com o Due, você obtém uma porta USB nativa, para a qual você pode rolar seu próprio driver CDC, se desejar. Algumas das placas STM32 também possuem USB nativo.

Se eu entendi a pergunta, o que se resume a tomar mensagens de hora / local do GPS em uma linha serial e correlacionar as mensagens de dados de alcance recebidas em outras linhas seriais. Idealmente, as mensagens do localizador de intervalo teriam seu próprio registro de data e hora e, se você pudesse sincronizar todos os relógios, seria possível identificar o local em que o intervalo foi obtido interpolando o registro de data e hora do intervalo entre as duas mensagens gps com o carimbos de data e hora correspondentes mais próximos. Mas é claro que você não tem isso.

Algumas soluções vêm à mente, ao longo de todas as linhas do uso de um microcontrolador para fazer a correlação de dados em tempo real e bombeando a saída disso para o PPC para fins de exibição. Basicamente, o microcontrolador existe para lidar com os problemas de tempo apertado.

Portanto, para uma solução mais simples, tudo o que você precisa é de uma maneira de coletar todas as mensagens de várias linhas seriais diferentes e combiná-las em um único fluxo, na ordem em que foram recebidas, e bombear isso para o PC. Você pode deduzir que qualquer mensagem do telêmetro entre duas mensagens GPS ocorreu em algum momento entre essas duas mensagens.

Isso fornece um certo grau de incerteza, dependendo da frequência das mensagens GPS. A desvantagem é que, à medida que você aumenta a frequência das mensagens GPS (para obter uma correlação mais precisa), aumenta as demandas no microcontrolador e as demandas no link serial no PC. No extremo, o link serial está saturado com mensagens GPS, com uma mensagem ocasional de alcance. Obviamente, a maioria dessas mensagens GPS não é necessária. A vantagem desta solução, porém, é que o micro tem muito pouco a fazer, do ponto de vista de software. Você pode fazer tudo isso em um loop simples de linguagem assembly, sem necessidade de SO.

Para uma solução mais complexa, você pode formar um relógio local no micro e usar o GPS para sincronizar esse relógio, para que, quando você receber uma mensagem de intervalo, obtenha um carimbo de hora usando o relógio do micro. Usando um micro com uma base de tempo de cristal, você provavelmente poderia se dar bem com mensagens de 1Hz GPS e ainda assim obter muito melhor do que os tempos de precisão de milissegundos impressos nas mensagens de alcance. Uma pessoa competente em sistemas embarcados provavelmente também poderia fazer isso em assembler em um micro de extremidade inferior, mas você mencionou que está apenas começando. Você pode olhar para um micro mais poderoso que pode rodar o Linux e, provavelmente, encontrar uma solução pré-existente para sincronizar o relógio do Linux com o GPS.

O que eu provavelmente faria é multiplexar os dados seriais em um novo fluxo de dados seriais a uma taxa alta, com um intercalamento estático. Em seguida, alimente o fluxo de dados através do USB-UART no computador. Dessa forma, você saberia que o primeiro byte é do dispositivo 1, o segundo byte do dispositivo 2, o terceiro byte do dispositivo 3 e, nesse caso, um quarto byte como CRC ou número de sequência. Coloque alguns bytes no início do marcador de quadro para sincronizar no fluxo de dados, preenchendo bytes se não houver dados disponíveis e pronto. Você pode não saber o tempo absoluto, mas sabe que o tempo relativo entre os vários blocos de dados.

Eu também usava um microcontrolador para receber os dados RS, registrá-los com data e hora e encaminhá-los para o PC. Você não pode executar nenhum trabalho crítico de tempo de E / S com um PC com Windows (exceto com uma placa de som, talvez), porque o software e os drivers estão mudando o tempo todo à medida que os drivers são atualizados nas suas costas.

Mas a primeira coisa que eu faria é obter um analisador lógico USB, você pode comprar um por menos de US $ 100, pegar algumas mensagens do receptor GPS e verificar exatamente quando cada byte é recebido. Use essas informações para testar / calcular exatamente o quão preciso é o tempo dos dados: por exemplo, exatamente o que e quando a caixa GPS transmite. Depois, você pode descobrir qual precisão é alcançável e quanto esforço você estaria disposto a ter para obter um certo nível de precisão.

Acima, uma foto de algum analisador lógico USB (Saleae?).

[Editar] Haha, usar a placa de som pode ser uma maneira engraçada de fazê-la realmente funcionar; você pode conectar os dados do UART à entrada da placa de som (através de alguns resistores e capacitores) e escrever um software para detectar cada extremidade do fluxo serial, fornecendo uma precisão de tempo bonita. Ok, eu realmente não estou sugerindo isso a sério, apenas por algumas risadas!