Como encontrar a linha UART é gratuita para enviar dados

Eu tenho várias placas que se comunicam com o Rs485. Eles possuem ATMegamicrocontroladores em série como atmega168pou atmega8. Cada placa é livre para enviar dados a qualquer momento e eu tenho limitações que levam a que eu não possa usar o Modbus . O número de placas pode variar de 5 a 10.

Meu problema é: como uma placa pode descobrir se a linha UART está livre para enviar dados e se detectar que o ônibus está ocupado, aguarde até que o ônibus esteja livre e envie os próprios dados?

Existe uma bandeira ou registro especial que possa alterá-la automática ou manualmente e permitir que a outra placa descubra que a Linha está ocupada ?

Bem-vindo ao maior desafio dos sistemas de comunicação half-duplex.

O RS-485 não é um protocolo, é um padrão que define as propriedades elétricas de um link diferencial half-duplex (*). Não há nada na especificação sobre como os dados devem ser enviados por esse link ou, de fato, como o link é usado.

Como esses transceptores RS-485 não possuem sinal / sinalizador automático de linha está ocupada, nem os microcontroladores que possuem drivers RS-485 integrados, nem os que usam um núcleo UART conectado a um transceptor externo.

Toda a implementação do controle de fluxo e controle de direção é deixada para qualquer protocolo que você use. Existem vários protocolos conhecidos que usam drivers RS-485, como o Modbus. Você também pode implementar qualquer protocolo que possa imaginar.

Para ajudá-lo, estas são algumas idéias para protocolos:

1. Você tem um protocolo do tipo mestre-escravo. Neste, existe um nó mestre que coordena o barramento e nós escravos, cada um com um identificador único.

   Os nós escravos não têm permissão para enviar nenhum dado até que o nó mestre envie especificamente os comandos endereçados a eles. Depois que um escravo é endereçado, ele pode responder a qualquer comando de uma maneira predefinida - digamos, um pacote de resposta de comprimento fixo.

   Nesse caso, você evita problemas de vários dispositivos que desejam conversar ao mesmo tempo, porque o mestre está lá para coordenar tudo.

2. Você pode usar alguma forma de agendamento em que cada dispositivo no barramento possui um slot fixo no qual enviar dados para qualquer outro dispositivo. Quando o slot acabar, ele deve parar de enviar e permitir que o próximo dispositivo fale.

   O agendamento pode ser feito pelos próprios dispositivos sem coordenação externa. O primeiro dispositivo fala e envia uma mensagem dizendo que está pronto. O próximo dispositivo (por exemplo, aquele com o próximo ID mais alto) saberia que poderia funcionar. Caso um dispositivo não esteja respondendo, você poderá ter um tempo limite em que cada dispositivo subseqüente no cronograma poderá dizer - bem, eu não tenho notícias do dispositivo antes de mim há um tempo, então deve ser minha vez.

(*) Acredito que também define uma versão full-duplex usando dois links diferenciais.

É muito semelhante à radiocomunicação dos militares ou da polícia. É necessário um protocolo. O escravo mestre é fácil e bom para a maioria dos casos. Mas outra opção é fazê-lo como os humanos:

1. Ouço.
2. Se alguém falar, espere.
3. Se você acha que ninguém fala, você pode falar.
4. Aguarde confirmação.
5. Se nenhuma confirmação for recebida, fale novamente.
6. Se você deseja transmitir, peça a todas as estações para confirmar a audição.
7. Se você quiser conversar com alguém que não pode ouvi-lo, pergunte se há alguém que possa retransmitir.

E assim por diante. Pode ser muito interessante de implementar. Boa sorte!

Aqui estão algumas possibilidades para resolver seu dilema.

1. Implemente um sistema de passagem de token. Quando um dispositivo possui o token, ele pode transmitir por um período limitado de tempo. Em seguida, ele passa o token para o próximo dispositivo. Devem ser feitas provisões para nós ausentes que não podem receber e passar o token.
2. Olhe para a linha de recebimento. Se estiver ocupado, gere um atraso aleatório e tente novamente. O atraso aleatório ajuda a garantir que nenhum nó possa monopolizar as janelas de transmissão. Ainda podem ocorrer colisões, mas um recurso de soma de verificação pode determinar se o pacote recebido está intacto. Se não estiver intacto, o receptor pode solicitar uma retransmissão.

Como um conselho pode descobrir se a linha UART está livre para enviar dados,

a resposta geral é que, sem algum tipo de protocolo, ele não pode fazê-lo de maneira confiável. você normalmente depende de um controlador ou árbitro para ver se uma linha está ocupada ou não. Um simples seria um pino OD puxando uma linha indicadora para baixo antes da transmissão e liberando-a depois. Ao ler essa linha, um transmissor pode determinar se o barramento está disponível ou não.

um sistema menos confiável, porém mais simples, é integrar a tensão do barramento (via rede ar / c, por exemplo).

e se detectar que o barramento está ocupado, aguarde até que o barramento esteja livre e envie seus próprios dados?

a abordagem geral é aguardar um período aleatório e tentar novamente.

Eu resolvo esse problema com meus projetos, desta maneira:

em vez de usar 2 pinos para comunicação, eu uso 3 pinos. Dentro de distâncias curtas, ele funciona. O terceiro pino é o indicador de linha ocupada. Este pino é puxado para cima do lado mestre. Quando alguém (MCU ou o que quer) quer falar:

• verifica esse estado do pino (INPUT).
• se o pino estiver ALTO, o pino estará baixo (SAÍDA)
• e conversas.
• Quando a mensagem é transferida, libera o pino (INPUT) (alta impedância) e o pino fica alto.
• Se o pino estiver baixo, aguarde um pouco e volte para verificar o ciclo do pino.

Esta é uma implementação da resposta de Gregory Kornblum.

Você pode usar a pilha de protocolo BACnet de código aberto para comunicação por microcontrolador no RS485, se não quiser usar o modbus. Essencialmente, ele apenas passa um token que informa a cada dispositivo quando ele pode enviar, semelhante à topologia de token-ring e à Ethernet. Aqui estão alguns links para você começar:

http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/

Controle de fluxo de software

O controle de fluxo de software e hardware precisa de software para executar a tarefa de handshake. Isso torna o termo controle de fluxo de software um tanto enganador. O que se quer dizer é que, com o controle de fluxo de hardware, outras linhas estão presentes no cabo de comunicação, sinalizando condições de handshake. Com o controle de fluxo de software, também conhecido sob o nome de controle de fluxo XON-XOFF, os bytes são enviados ao remetente usando as linhas de comunicação padrão.

O uso do controle de fluxo de hardware implica que mais linhas devem estar presentes entre o remetente e o receptor, levando a um cabo mais espesso e mais caro. Portanto, o controle de fluxo de software é uma boa alternativa se não for necessário para obter o máximo desempenho nas comunicações. O controle de fluxo de software utiliza o canal de dados entre os dois dispositivos, o que reduz a largura de banda. A redução da largura de banda é na maioria dos casos, no entanto, não é tão surpreendente que é um motivo para não usá-lo.

Dois bytes foram predefinidos no conjunto de caracteres ASCII para serem usados ​​com o controle de fluxo do software. Esses bytes são nomeados XOFF e XON, porque podem parar e reiniciar a transmissão. O valor de byt do XOFF é 19; pode ser simulado pressionando Ctrl-S no teclado. XON tem o valor 17 atribuído, que é equivalente a Ctrl-Q.

É fácil usar o controle de fluxo de software. Se o envio de caracteres precisar ser adiado, o caractere XOFF será enviado na linha, para reiniciar a comunicação novamente, o XON será usado. O envio do caractere XOFF apenas interrompe a comunicação na direção do dispositivo que emitiu o XOFF.

Este método tem algumas desvantagens. Já se discute: o uso de bytes no canal de comunicação ocupa uma certa largura de banda. Um outro motivo é mais grave.

O handshaking é usado principalmente para impedir a saturação do buffer do receptor, o buffer da memória usado para armazenar os bytes recebidos recentemente. Se ocorrer uma saturação, isso afeta a maneira como os novos caracteres no canal de comunicação são tratados. Na pior das hipóteses, quando o software foi mal projetado, esses caracteres são jogados fora sem verificação. Se esse caractere for XOFF ou XON, o fluxo de comunicação poderá ser severamente danificado. O remetente fornecerá continuamente novas informações se o XOFF for perdido ou nunca enviará novas informações se nenhum XON tiver sido recebido.

Isso também vale para linhas de comunicação em que a qualidade do sinal é ruim. O que acontece se a mensagem XOFF ou XON não for recebida claramente devido ao ruído na linha? Também é necessária precaução especial para que as informações enviadas não contenham os caracteres XON ou XOFF como bytes de informações.

Portanto, a comunicação serial usando o controle de fluxo de software é aceitável apenas quando as velocidades de comunicação não são muito altas e a probabilidade de excedentes de buffer ou danos nos dados é mínima.

CSMA de alta velocidade

Para alta velocidade como detecção de portadora CSMA Ethernet , acesso múltiplo, detecção / prevenção de colisão, com temporizadores de retorno aleatórios, foram analisados ​​para verificar a probabilidade estocástica em busca de otimização.