Bons protocolos baseados em RS232 para comunicação incorporada ao computador

Estou trabalhando em um projeto que envolve uma boa comunicação de dados entre um Arduino remoto e um computador. A conexão sem fio é através de um par de XBees, portanto, temos um link RS232 entre o Arduino e o computador. Para pequenas quantidades de dados, é fácil reunir algum protocolo de comunicação simples. Para projetos maiores, no entanto, quais são alguns bons protocolos de comunicação simples?

Eu olhei para o MODBUS, que parece uma opção viável, mas eu queria ver se havia outras opções melhores.

O OP solicita um protocolo serial para uma situação em que " poucos dados e velocidade não são um grande problema ". O MODBUS é mencionado no OP MODBUS sobre RS-485 não é um protocolo rápido. Embora isso não seja uma especificação, isso dá uma idéia sobre o nicho.

Só consigo pensar em dois protocolos padrão comuns para esse nicho:

• NEMA 0183 . Protocolo ASCII de texto sem formatação. Legível por humanos. Somente ponto a ponto. Não suporta barramento multiponto.
• MODBUS, que já foi mencionado no OP

Muitas vezes, quando os programadores incorporados estão em uma situação como o OP, eles projetam seus próprios protocolos de comunicação serial do zero.

Alguns protocolos de sistema embarcado, vários deles extremamente simples, estão listados em Sistemas embarcados: Protocolos comuns , incluindo:

• Rede embarcada minúscula (RTE)
• Intérprete de microcontrolador para sistemas embarcados em rede (MINES)
• Outro protocolo escalável (YASP)
• Rede de interconexão local (LIN)
• Servo controlador serial (SSC)
• Sistema operacional do robô ( serial )
• rede
• vários ônibus de campo
• Modbus
• Rede de Área do Controlador (CAN)
• Firmata (Obrigado, jippie!)

Talvez um desses protocolos seja adequado para sua aplicação como está, ou com apenas pequenos ajustes.

Eu votaria na sua e manteria o mais simples possível.

Eu lidei com muitos protocolos de série para várias aplicações de controle e algumas coisas que eu posso recomendar você incluir são:

• Iniciar e parar caracteres que não são usados ​​em outro lugar
• Algum tipo de soma de verificação / verificação de erro
• Algum método de controle / sinalização de fluxo, especialmente se você precisar de comunicações bidirecionais.

Como um exemplo muito básico, você pode converter seus dados em caracteres ASCII e inseri-los em caracteres de início / parada como este:

Para enviar o valor de byte 0x7A, os dados enviados seriam (7A), onde os () são os caracteres de início / parada escolhidos e 7 e A são dois caracteres ascii. OK, acrescenta muita sobrecarga, mas significa que você pode depurar com o software básico do terminal.

Se seus dados estiverem passando pelo XBees, você deverá colocar os módulos no modo API com caracteres de escape, dividir seus dados em pacotes lógicos e aproveitar o fato de que, no modo API, um pacote fornecido a um XBee chegará intacto ou de modo nenhum. Projete seu protocolo em torno da transmissão de pedaços de 1 a 255 bytes e deixe os módulos XBee se preocupar com a forma de entrega dos dados em cada pedaço. Não se preocupe em manter a integridade de pacotes individuais ou as subdivisões entre eles. Os módulos Digi farão um bom trabalho cuidando disso. A maior coisa com a qual você precisa se preocupar é o fato de que, mesmo que o nó que transmite um pacote acredite que não foi entregue e envie uma substituição, o destinatário pode acabar obtendo a mesma de qualquer maneira - possivelmente mesmo após a substituição. As coisas podem ser mais fáceis se você projetar seu protocolo para que um lado seja o "mestre"; se o mestre solicitar um dado, o escravo deve enviá-lo uma vez e não se preocupar se o mestre o obtém. Se o mestre não obtiver os dados que deseja, poderá solicitá-los novamente.

O escravo deve atribuir algum tipo de número de sequência aos dados, e o mestre deve atribuir números de sequência a solicitações que o escravo mude de estado. Se a solicitação do mestre for do formato "envie o primeiro item cujo número de sequência seja maior que XXX", e cada item de dados do escravo incluirá seu próprio número de sequência e o do item anterior (se não forem numerados consecutivamente ), pacotes de chegada tardia podem fazer com que o escravo envie dados de forma redundante ao mestre, mas o mestre não terá dificuldade em ignorar as conseqüentes respostas de chegada tardia. Se o escravo receber uma solicitação de mudança de estado cujo número de sequência estiver abaixo do pedido anterior, deverá ignorá-la, pois foi substituída antes mesmo de ser recebida.

E o Firmata ? Possui suporte para vários sistemas operacionais e linguagens de programação. O lado do controlador Arduino e o PICduino são suportados, mas isso não deve ser muito difícil de transportar para um microcontrolador simples.

Eu tinha uma pergunta semelhante a essa e nunca encontrei nada simples e pequeno o suficiente para pequenos AVRs etc. Por isso, lancei algo inspirado no CAN. Chama-se MIN (Microcontroller Interconnect Network):

https://github.com/min-protocol/min

Eu escrevi sobre isso aqui:

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

Existem ganchos para os dados do bloco, mas são principalmente direcionados a sinais para sensores / atuadores. Eu defini um formato JSON para descrever os sinais e suas embalagens nos quadros MIN e espero obter um dissector do Wireshark que o utilize.