Pesquisa de sensor via interface serial USB-RS485 travada em 16ms, mesmo que deva ser mais rápida


8

Eu tenho uma configuração, conectando uma placa do sensor Razor IMU , com uma placa RS-485 Breakout , a uma interface serial USB-RS485 via cabo USB no meu laptop. Eu executo um software no laptop (Max / MSP) que envia mensagens de pesquisa ao sensor, aguarda os dados de resposta e, ao receber a resposta, dispara automaticamente uma nova mensagem de pesquisa. É um loop constante:

  1. envie uma mensagem de pesquisa
  2. aguarde uma resposta
  3. em resposta, vá para 1.

Quero que essa pesquisa seja o mais rápida possível, pois terei de conectar 21 desses sensores ao mesmo barramento RS485. O firmware do Razor é programado com o Arduino IDE e, de acordo com o código, deve haver apenas um atraso de ~ 2ms entre a mensagem de pesquisa e a gravação da resposta. O firmware também gasta 12ms a cada 20ms em alocação e cálculo de sensores. Às vezes, esse cálculo atrasa a resposta à pesquisa. Estou ciente disso e todos os resultados estão em conformidade.

Meu problema agora é que a pesquisa do sensor está travada a uma taxa de atualização de 15 milissegundos em média. Olhei para os dados com meu pequeno osciloscópio usb e fiz um diagrama (> PDF).

insira a descrição da imagem aqui

Meu osciloscópio fica diretamente na interface USB-RS485 e vê o polling sair, e a mensagem de resposta é recebida. O atraso entre esses dois fica entre 2 e 13 ms. Essa diferença é explicável pelo fato de que, às vezes, a máquina de barbear está ocupada fazendo seus cálculos de matemática-sensor. O fato estranho é que, embora as respostas cheguem com atrasos diferentes, a pesquisa sempre sai no mesmo intervalo de cerca de 15ms.

Também implementamos a mesma configuração com

  • codificando o firmware em C e programando o Razor com avr-dude
  • fazendo a pesquisa de software no código Python
  • no Mac OSX e PC Windows 7

Todas as combinações possíveis resultaram no mesmo intervalo de 15 ms. Portanto, o problema não está no código do Arduino, nem no Max / MSP. Suspeito que o problema possa estar relacionado à interface serial USB-RS485 e / ou ao driver FTDI necessário.

Esse problema parece familiar para alguém?


Então a pesquisa está sempre acontecendo em um computador executando o OSX ou o Windows 7? O atraso no USB pode ser bem grande, independentemente da linguagem de programação usada.
Kellenjb

No momento, estamos testando no Windows 7 e no OSX. no final, ele será executado no Windows 7.
evsc 20/03/2012

2
Em vez de editar sua pergunta, você pode responder sua própria pergunta. Isso permitirá que você a selecione como resposta e até receba votos!
Kellenjb

em 7 horas eu vou! :) <.... Usuários com menos de 100 reputação não podem responder sua própria pergunta por 8 horas depois de fazer a pergunta. Você pode responder automaticamente em 7 horas. Até lá, por favor, use comentários ou edite sua pergunta.>
evsc

Respostas:


5

Isso se deve ao timer de latência de 16ms do driver FTDI e ao fato de que minhas respostas à pesquisa não foram longas o suficiente para preencher o buffer de 64 bytes para acionar automaticamente o esvaziamento do buffer. Leia AN232B-04_DataLatencyFlow.pdf se você estiver interessado, ou simplesmente vá para o Gerenciador de dispositivos e altere as configurações nas propriedades da porta serial USB.


2

Sem conhecer muitos detalhes (o que realmente não quero saber), eu culparia o adaptador USB para RS-485. Tivemos um problema semelhante em um processador Intel Q7 executando Linux com um desses adaptadores.

Estávamos usando o adaptador temporariamente até que nosso hardware personalizado estivesse pronto. Nosso hardware personalizado usa um link PCIe e um FPGA para fazer a mesma interface RS-485 (e muito mais). O software permaneceu o mesmo para o adaptador e nosso hardware personalizado. Quando mudamos para o hardware personalizado, o problema desapareceu.


sim! só descobri que eu posso mudar um monte de coisas nas configurações USB-Serial portas (especialmente o temporizador de latência) e, em seguida, tudo se acelera ...
EVSC
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.