Enviando/Recebendo dados usando topologia tipo anel sobre RS-232

Além disso, em muitos casos uma pequena rede de dispositivos usando a RS-232 poderia resolver, e bem, um caso bem específico. Porém os problemas surgem quando desejamos conectar mais de um dispositivo em rede usando a RS-232, que em teoria, não foi desenvolvida para isso. A experiência a ser apresentada nesse artigo visa ajudar os que pretendem evoluir no assunto, servindo de base para seus estudos.

A inspiração: IEEE 802.5 Token Ring

O Token Ring é formado por dispositivos ou estações (geralmente computadores ou similares) conectados em formato de "anel" conforme a figura abaixo.O princípio usado nesse tipo de rede é que um "token" fica circulando entre os anéis e qualquer dispositivo que esteja com esse token terá o direito de transmitir os dados. Sempre que uma estação deseja transmitir um frame de dados, ela inverte um único bit do token de 3 bytes que o transforma instantaneamente em um pacote de dados normal.Como há apenas um token, só pode haver uma única transmissão por vez.

Como o token gira no anel, é garantido que cada dispositivo receba o token em um tempo especificado. Portanto, há também um limite máximo de espera para receber o token. Também há um limite máximo de 250 dispositivos nesse tipo de rede.Para distinguir os pacotes de dados normais do token (pacote de controle), uma sequência especial é atribuída ao pacote token. Quando qualquer dispositivo obtém o token, ele primeiro envia os dados que deseja enviar e, em seguida, recircula o token.

Sobre o exemplo que será apresentado

No exemplo apresentado nesse artigo foi inserido apenas a parte da circulação dos dados, já que a ideia era simplificar o tipo de dispositivo, três microcontroladores e um microprocessador das décadas de 1970/1980, ao invés de utilizar computadores, permitindo assim que tais elementos pudessem ser utilizados nesse exemplo.

Então o que posso dizer é que o que temos são dispositivos RS-232 conectados entre si, formando um anel, mas sem que isso interfira nas conexões, já que a norma RS-232 prevê a conexão de apenas dois dispositivos entre si por porta (sem adicionais), conforme demonstrado na figura abaixo.

No exemplo, o que eu fiz foi conectar 4 dispositivos RS-232 usando a topologia "Ring" (anel), de maneira que o primeiro elemento está conectado ao segundo e este por sua vez ao terceiro, que se conecta ao quarto e este por fim se conecta ao primeiro, fechando o anel. Veja a figura abaixo para entender melhor o que foi dito.

Perceba que nessa rede, o ponto TX (envio) de todos os dispositivos está conectado ao ponto RX (recepção) do próximo dispositivo em relação a cada um. E assim, por exemplo, para que o ponto 1 envie uma mensagem para o ponto 4, o pacote precisará passar pelos pontos 2 e 3, nessa ordem. E qualquer resposta entre qualquer ponto também segue a mesma regra. Note que pela figura a comunicação se dá sempre em sentido anti-horário.

A mensagem sempre "gira" no anel de um dispositivo a outro até chegar ao seu destino, e a resposta do dispositivo que recebeu para o dispositivo que enviou caminha da mesma forma. Não há como, por exemplo, o dispositivo nr 4 se comunicar com o dispositivo nr 3 sem que a mensagem vinda do nr 4 passe pelo nr 1 e nr 2 até chegar ao nr 3. Porém nesse caso a resposta do dispositivo nr 3 encontra na sua sequencia o dispositivo nr 4. Mas veja que se pegarmos como exemplo o envio do nr 1 para o nr 3, a mensagem passaria pelo nr 2 e a resposta pelo nr 4.

O protocolo

O protocolo criado é bem simples, mas facilita bastante o uso e entendimento, em relação a qualquer outro protocolo (lembrando que isso é apenas um exercício ("brincadeiras e experiências"), que visa auxiliar qualquer um que queira ampliar seus horizontes!. O formato do protocolo está abaixo:

<HEADER><NR DOS DISPOSITIVOS><QUANTIDADE DE BYTES DA MSG><BYTES DA MSG>

Com:

• HEADER => 40H (Caracter "@");
• NR DOS DISPOSITIVOS => no MSB nr do sender, no LSB nr do receiver;
• QUANTIDADE DE BYTES DA MSG = 1 à 14 máximos (neste exemplo);
• BYTES DA MSG = Mensagem do sender ao receiver ou ACK obrigatório (resposta da mensagem recebida).
  

Também ainda sobre o protocolo, como não há um token "girando" constantemente que possa ser utilizado pelo dispositivo que precisa enviar algo, cada dispositivo tem implementado um "alerta" interno que o impede de receber qualquer coisa caso o mesmo esteja em "estado de envio" e também de enviar em caso de estar em "estado de recepção". E para evitar que os dados sejam perdidos é só ativar o reenvio da mensagem sempre que o ACK de confirmação não chegar dentro de um tempo predeterminado. Isso funciona bem para dispositivos que trabalham com ativação pela mão "humana" e, até certo ponto, para dispositivos automáticos desde que não muito rápidos.

Um outro detalhe que acredito foi percebido, é que nesse pequeno protocolo só é possível ter 15 dispositivos máximos, já que o mesmo byte carrega o nr do sender e o nr do receiver (quem envia e quem recebe). Esse pequeno problema pode ser facilmente resolvido adicionando mais um byte, então teríamos um byte para o nr do sender e um byte para o receiver. Isso aumentaria para até 255 dispositivos na rede.

O número de bytes na mensagem foi limitado a 14 para facilitar o uso dos LCD's presentes na experiência e também devido ao fato de um ou outro dispositivo presente na "rede" não possuir grande área de memória RAM para troca de dados, como é o caso do PIC utilizado que possui apenas 256 bytes de RAM para a versão 16F648A (e 224 bytes caso a versão fosse o PIC16F628A). Isso pode ser contornado inserindo nos "bytes da mensagem" um segundo protocolo que permita transferir pacotes numerados! Teria-se então um protocolo encapsulado por outro, ou uma transmissão de dados em camadas (mais ou menos como acontece com o TCP/IP).

A experiência

Para realizar essa experiência eu utilizei 4 "dispositivos" bastante distintos e diferentes entre si, que são:

• 1 microprocessador Z80;
• 1 microcontrolador PIC16F648A;
• 1 Arduino Uno (microcontrolador AVR ATMEGA328);
• 1 módulo BluePill (microcontrolador STM32F103C8T6).
  

Para o primeiro da lista a programação foi feita em Assembly Z80 e para os demais, Linguagem C (cada qual com as suas particularidades).

O PIC assume o dispositivo nr 1, o Arduino nr 2, o STM32 nr 3 e o microprocessador Z80 o nr 4. O Z80 é um microprocessador e não possuí USART's, TIMER's e outros recursos internos. Por isso a parte do reenvio não está presente aqui, mas não foi necessária. Para implementar isso na rede, seria necessário o uso de um timer externo conectado ao Z80 (não perca os próximos capítulos dessa nova saga!!!).

Para o hardware dessa experiência usei os seguintes itens:

• Z80: Microcomputador Z80 by Arne;
• PIC: Placa de estudos PE-PIC16F628A by Arne;
• Arduino: Arduino Uno com LCD Keypad Shield e Conversor RS-232/TTL duplo by Arne;
• STM32: Placa de estudos PE-STM32 by Arne (link em breve!);

Mais abaixo, em Downloads, eu deixo o pacote com os programas desenvolvidos para cada um dos elementos presentes nos meus testes para estudos, alterações e outros que deseje realizar.

Downloads:

- Pacote com arquivo Arduino (compilador Arduino-cli ou Arduino IDE);
- Pacote com arquivos PIC (compilador XC8 Microchip);
- Pacote com arquivos STM32 (compilador SW4STM32 e biblioteca Standard Peripheral Lib);
- Pacote com arquivos Z80 (compilador Pasmo).

Este projeto foi publicado em Maio de 2023 no site do Arne (http://www.arnerobotics.com.br) e divulgado no Youtube através do seu canal em https://www.youtube.com/c/arnesake.

Especificações:

- Cérebro  - Arduino Uno, PIC16F648A, STM32F103C8T6 e Z80
- Saídas   - LCDs e matriz de LEDs 
- Entradas - Chaves
- Programa - Linguagem C (Arduino, Pic e STM32) e Assembly (Z80)