Balada de transferência de dados
Nas primeiras linhas da minha hemorragia de texto, quero dizer o seguinte: Já foi escrito muito sobre isso, também vou escrever minha visão. As interfaces padrão para transmissão de informações são ótimas, mas, para minhas necessidades, elas não fornecem transferência de dados satisfatória (boa ou quase) suficiente. Vou tentar fazer algumas adições para levar isso ao estado que me convém.Existem 2 ou mais dispositivos a uma distância suficientemente grande (1-100 metros) entre os quais os dados devem ser transmitidos. Tendo examinado algumas interfaces (rs232 / 422/485, I2C, Ethernet), cheguei à conclusão de que elas não garantem uma transferência inequívoca de dados, também não gostei de muitos fios, e não respondem que a informação é aceita. Decidi tomar a interface RS485 como base - ela pode ir muito longe de suas vantagens, 2 fios, você pode conectar vários dispositivos ao mesmo tempo, é simples, (UART) está em quase qualquer controlador.No meu caso, o esquema clássico 1 que lidera o resto dos escravos é adequado para mim. O algoritmo do sistema de mensagens é o seguinte: os dados são transmitidos em ciclos de troca, um ciclo de troca consiste em uma mensagem que é transmitida do mestre para o escravo, em resposta o mestre recebe a mensagem do escravo, todos os outros ficam em silêncio. Na mesma base, implemente uma solicitação de dados de um dispositivo escravo.
Um ciclo de troca.Para atender às minhas necessidades de transferência de dados, preciso resolver apenas duas perguntas. Pergunta 1: a verificação do byte transmitido é baseada na própria interface RS-485, mas não garante um byte transmitido de forma confiável - se um byte for encontrado na própria interface, ele será jogado fora dos dados recebidos, mas ainda é possível transferir o byte errado - se ele mudou (ficou ruim) ) um número par de bits em um byte. isto é é necessária uma verificação do número de bytes transmitidos e da validade dos bytes nos dados transmitidos.Pergunta dois: recebendo uma mensagem de resposta para a transmitida.Na primeira pergunta: esse esquema é proposto: o byte inicial, o byte do número decaracteres transmitidos em toda a mensagem, outra coisa, o byte de soma de verificação (BCS), o byte final.
Nota: o byte da soma de verificação deve ser considerado o módulo 2.Com base no esquema proposto, pode-se julgar que, se a resposta não retornar, o seguidor não estará disponível. Nesse caso, são possíveis opções quando uma mensagem danificada chega ao seguidor e ele não responde, ou a mensagem chega até ele e ele envia a resposta, mas a resposta fica ruim e o líder a ignora.Para corrigir isso, foi aceito: se a resposta não vier (ou vier, mas não for confiável), repita (o número de vezes sem insanidade) repita o atual ciclo de troca. O seguinte erro pode ocorrer aqui. Suponha que enviemos um comando informando ao dispositivo que você precisa aumentar o volume em +1 unidade. Quando a mensagem chega ao escravo, ele executa o comando para aumentar o volume e envia a resposta "ok, eu fiz como você queria", mas pode acontecer que a resposta fique ruim e o apresentador não entenda que o comando já foi executado e envie a mensagem novamente. Como resultado, ao receber um comando no lado escravo, o volume já será adicionado por +2 unidades. Para evitar esse fenômeno, é habitual introduzir um identificador (NS - número da mensagem) da diferença de mensagem. Se o número da mensagem for repetido, será uma mensagem repetida e o comando especificado não precisará ser executado,mas basta enviar a mensagem de resposta anterior.Também digito aqui mais 2 parâmetros - este é o número (código) do dispositivo para o qual os dados são transmitidos e o número (subcódigo) indicando qual comando deve ser executado (ou quais dados estão dentro da mensagem).
Como resultado, reunirei tudo e analisarei o algoritmo, usando o exemplo de aumento do limiar do relé por temperatura em 5 graus Celsius e obtendo a leitura de temperatura atual do escravo por 1 ciclo de troca: eugiro os dados transmitidos do mestre:
quando a mensagem é recebida, o escravo olha para 2 bytes, onde é o número de bytes enviados, se o número de bytes enviados for igual ao número de recebidos, a mensagem não perdeu bytes; então, veremos o byte inicial (caractere) se for = '$' e também o byte final (caractere) se for = ' # '- esta é uma mensagem de viajar para o escravo.Imediatamente considerarei as possíveis opções de mensagem do mestre para o escravo com erros nos bytes inicial e final, bem como a opção com um erro no número de bytes na mensagem. Farei uma reserva imediatamente a partir de 3 valores de parâmetros que considerarei corretos 2 e 3, ou seja, se 2 parâmetros de 3 possíveis coincidem, considero a mensagem válida.1. start byte = '$', número de bytes recebidos = 7 (número de bytes enviados = 7), o byte final não é igual a '#';
2. o byte inicial não é igual a '$', o número de bytes recebidos = 7 (o número de bytes enviados = 7), o byte final = '#';
3. start byte = '$', número de bytes recebidos = 7 (número de bytes enviados = 7, número de bytes não é 7), byte final = '#'.
Em seguida, calculamos a soma de verificação dos 3 bytes restantes (bytes 3, 4, 5); se coincide com o BCS, continuamos analisando os dados, analisamos esses dados para este dispositivo e o que deve ser feito nele; no nosso caso, o código escravo é 55 e o subcódigo 2 diz sobre a necessidade de adicionar mais 5 graus ao limite do relé e na mensagem de resposta para enviar os dados de temperatura atuais. Verifico o NS se não é igual ao número da mensagem anterior e, em seguida, executo o comando e adiciono 5 graus ao valor atual do limite do relé. Se eles são iguais (NS), então eu não executo as ações indicadas, então prossigo para a formação de uma mensagem de resposta.aplicação do esquema ['$'] [número de bytes enviados / recebidos] [...] ['#'] - com alta probabilidade garante que essa combinação não poderá ser encontrada nos dados transmitidos e provoca uma mensagem falsa.Formo os dados transmitidos do escravo com base na mensagem recebida:
O princípio do processamento é o seguinte: observe 2 bytes em que o número de bytes enviados é, se o número de bytes enviados for igual ao número de bytes recebidos e também o byte inicial = '@' e o byte final = '&' - esta é uma mensagem do escravo para o mestre. Se necessário, eu uso o mecanismo 2 de 3, semelhante ao descrito acima apenas para a mensagem de resposta (para os caracteres '@' e '&'). Ao receber esta mensagem, o host analisa a soma de verificação 9 (do 3º ao 11º) bytes, se a soma de verificação corresponder, os dados na mensagem serão considerados confiáveis e uma análise de dados adicional continuará. Se o código, o subcódigo e o NS das mensagens enviadas e recebidas coincidirem, continuaremos analisando a resposta à mensagem enviada pelo host. A seguir, é apresentada a análise dos dados recebidos,no meu caso, no sexto byte, um valor de 1 significa que o comando para aumentar 5 graus até o limiar do relé foi bem-sucedido, os 5 bytes restantes indicam as leituras de temperatura atuais; o 7 byte é um sinalizador que indica a confiabilidade da temperatura transmitida (ou seja, Estou considerando a opção em que o escravo está ligado e respondendo, mas o sensor pode não funcionar) e 4 bytes do tipo valores de temperatura de flutuação.O uso de 2 caracteres de teste no início e no final de uma mensagem com alta probabilidade garante que, em caso de erro, não confunda mensagens do escravo e do mestre. Também dados aleatórios (não aleatórios) no canal não estragam a troca.Um pouco sobre a transmissão de dados do escravo para o escravo e uma mensagem centralizada para todos os escravos do mestre.Primeiro, o último - a transmissão do mestre pelo escravo é realizada atribuindo o código do dispositivo 255, que informa ao escravo que esta é uma mensagem centralizada, resta apenas resolver o problema dos subcódigos comuns, podendo também ser agrupados por códigos de dispositivo atribuir código de dispositivo 254 e 3 ou 4 dispositivos receberão uma mensagem usando esse código; o restante ignorará, naturalmente, a parte do envio de respostas de escravos não deve funcionar aqui, ou seja, não é garantido que os seguidores aceitem sem ambiguidade essas mensagens!Na transmissão de dados do escravo para o escravo, implementada pelo mestre envia uma mensagem ao escravo (escravo1) a partir da qual as informações devem ser enviadas para o outro escravo (escravo2), o escravo1 envia uma resposta ao mestre enquanto o escravo2 ouve essa resposta, levando os dados para si. Novamente, não há garantia de uma entrega inequívoca de mensagem do slave1 para o slave2; isso deve ser levado em consideração!Número de recursos de interface de dispositivos conectados teoricamente cerca de 250, tipos de comandos / dados até 248 para cada dispositivo, o comprimento da informação útil na mensagem é de até 250 bytes.Fale sobre as armadilhas:Toda a transferência de dados foi projetada para funcionar a tempo, ou seja, certos atrasos entre as mensagens devem ser observados. Eu também recomendo que você faça um atraso fixo entre a mensagem enviada pelo mestre e a resposta do escravo, para que o escravo possa gerar dados e transmiti-los completamente ao canal.O momento de organizar as respostas do escravo também é importante; pode acontecer que o escravo esteja ocupado e tenha várias mensagens de dados em seu canal ao mesmo tempo; evite respostas a mensagens desatualizadas (porque o líder não espera mais por elas) ignorando-as, executando comandos apenas das últimas mensagens e dê uma resposta.Separadamente, eu gostaria de destacar a questão da sincronização de dispositivos por tempo - deve-se ter em mente que a sincronização de tempo do escravo ao receber uma mensagem exige levar em consideração o atraso no envio de dados ao canal (a uma velocidade de 9600, uma mensagem de 10 bytes será transmitida por cerca de 11 ms) e o momento em que a interrupção é acionada no final recebendo dados no lado escravo, se não houver interrupção, vale a pena considerar o tempo de verificar a chegada de dados no buffer do dispositivo, etc.Também é importante notar que o reenvio de um loop de mensagens também adiciona nuances, eu recomendo o envio de mensagens sem repetições para sincronização de tempo e a composição de mensagens com um novo NS.PSTenho dúvidas de que descobri algo novo aqui, tudo isso até certo ponto é usado em algum lugar em diferentes interfaces! Com a mão leve do autor deste rabisco e a aplicação deste protocolo em meus desenvolvimentos, quero dar o nome a esse protocolo de transferência de dados “SRDB2”. Source: https://habr.com/ru/post/pt398791/
All Articles