PROTOCOLO DE COMUNICAÇÃO
SÉRIE RS-232
Realizado por:
Amândio Pereira………...010503121 Carlos Daniel……….050503245
Índice: Objectivos...pág 3 Introdução...pág 3 Descrição………...pág 4 Funções implementadas...pág 6 Ensaio………...pág 7 Análise………...pág 8 Anexos
OBJECTIVOS
O objectivo deste trabalho prático foi o desenvolvimento de um protocolo de comunicação série RS232 entre duas estações (PC’s), recorrendo à linguagem de programação C.
INTRODUÇÃO
A seguinte figura (fig.1) representa o “modelo em camadas” da comunicação que se pretende implementar:
Fig.1 - Modelo em camadas do protocolo
A camada física é constituída com um cabo c/ 3 condutores (Tx, Rx e Gnd), e as portas séries dos computadores. As tensões de trabalho são -12 e 12, respectivamente 1 e 0.
A ligação entre os dois DCE’s (Data Communications Equipment) é feita recorrendo a interfaces DB9 (9 pinos), embora só se usem 3 pinos:
Pino 2 - Rx Pino 3 - Tx Pino 5 - Gnd O tipo de transmissão é sem handshaking pois só se usam 3 condutores. A ligação entre os dois DCE’s é em Null Modem (cabo cruzado).
A segunda camada são os Device Drivers da porta série (/dev/ttyS0 e /dev/ttyS1) que são responsáveis pela leitura e escrita de sinais em tensão na porta série, estabelecendo a ligação com a Aplicação Lógica.
A terceira camada interliga uma aplicação de software com os device drivers. Foi sobre esta camada que o trabalho incidiu, logo será explicada mais à frente em detalhe.
A quarta camada será uma aplicação de software que faz uso do protocolo para comunicar. Não será muito abordada pois neste caso apenas foi criada para testar o protocolo.
DESCRIÇÃO
Neste ponto pretende-se explicar o funcionamento da aplicação lógica que está situada na terceira camada, já referida atrás.
Esta aplicação tem as seguintes características:
-Fornece um serviço fiável à camada superior.
-Função de framming: a informação é acondicionada em tramas -Estabelecimento (SET) e conclusão (DISC) da ligação.
-Controlo de erros c/ pedido de retransmissão e temporizadores.
Esta aplicação suporta dois tipos de tramas. As tramas de informação e as tramas de controlo:
SYN SYN SOH C L BCC DADOS BCC
SYN SYN SOH C L BCC
As tramas de controlo tem por função dar inicio e concluir a ligação e controlo de erros. As tramas de informação têm por missão a transmissão de dados.
A seguinte figura (fig.2) representa a sequência de uma ligação correcta e sem erros.
Fig.2 - Esquema de transferência de dados
Usando a técnica de encapsulamento de dados numa trama (framing) o receptor irá interpretar a informação enviada pelo emissor como uma sequência correcta de caracteres ordenados segundo uma lógica que tanto o emissor e o receptor entendem.
A trama é iniciada por dois ou mais caracteres SYN seguido de um SOH. Apesar de poder receber mais de dois SYN’s, a trama será vista sempre como tendo apenas dois.
Os caracteres iniciais SYN, SYN e SOH fazem parte do cabeçalho e servem para informar o receptor que se iniciou uma nova trama. O quarto octeto (C) é um campo de controlo.
O quinto (L) indica o número de caracteres de dados enviados no caso das tramas de informação e será zero no caso das tramas de controlo visto não serem enviados dados. O sexto octeto da trama de controlo é o BCC que serve para detectar erros através do Ou exclusivo (XOR) entre C e L. No caso das tramas de informação existe um segundo BCC no final da trama que faz o XOR entre todos os caracteres de dados como protecção.
Caso o BCC recebido seja diferente do calculado pelo receptor este rejeita a trama e pede ao emissor o reenvio da mesma.
Existe também um outro mecanismo de protecção que é o recurso à numeração das tramas alternando o seu valor entre zero e um, de forma a que não ocorram situações em que as tramas sejam omitidas ou repetidas. Isto é feito no octeto C.
Campo de controlo……...Descrição
SET………..Inicio da ligação DISC……...………. Fim da ligação
UA……….Confirmação de um SET ou um DISC RR……….Confirmação de uma trama de informação REJ………...…………Pedido de reenvio de uma trama de informação
FUNÇÕES IMPLEMENTADAS
Para implementar o protocolo de comunicação foram criadas 5 funções distintas:
Função header_checker - responsável pela detecção de uma sequência SYN, SYN (, SYN), SOH, para além de também ler os campos C, L e BCC.
Função llopen – estabelece a ligação lógica e define os parâmetros da comunicação, como seja o baudrate, o número de stop bits, bits de paridade, tipo de comunicação (assíncrona e não canónica)
Função llread – gere as tramas de dados que chegam à porta série, através do controlo e detecção de erros nas tramas ou sequenciamento incorrecto das mesmas
Função llwrite – responsável por enviar os dados correctamente para a porta série e pelo controlo do fluxo de dados
Função llclose – fecha a ligação lógica estabelecida anteriormente e repõe as configurações iniciais da porta série.
● A função llopen foi dividida em dois, de modo a garantir que esta responde quer como emissor quer como receptor, ficando assim com duas funções responsáveis por cada uma das situações (llopen_t e llopen_r).
Enquanto a função llopen_t envia a trama de controlo SET e fica a espera de receber a resposta durante 3s, após o qual retransmite a mesma trama, tentando a retransmissão mais quatro vezes. Se a comunicação for bem sucedida (envio e recepção das tramas SET e UA), a função retorna com o identificador da ligação lógica.
A função llopen_r espera receber uma trama de controlo do tipo SET do transmissor, que, em caso afirmativo faz a verificação do cabeçalho através da função header_checker, e se tudo tiver bem, responde com um UA, dando-se início a transmissão. Caso não receba nenhuma trama SET, a função espera durante um certo tempo, após o qual retorna um valor negativo ● A função llread começa por invocar a função header_checker que é responsável por verificar se o que recebeu corresponde ao inicio de uma trama (SYN-SYN-SOH), que em caso afirmativo verifica se a sequencia do cabeçalho esta correcta. Caso esta não esteja correcta, isto é, se não satisfizer a definição do campo de controlo necessário, pede para reenviar, num total de cinco tentativas, ao fim das quais retorna um valor negativo, indicativo de erro.
Se a sequência do cabeçalho for a correcta, vão-se recebendo os dados que podem chegar em parcelas inferiores ao total especificado no campo L. Se não se conseguir ler o número de dados esperados então a trama é rejeitada e é lida uma nova.
Após a recepção de todo o campo de dados é verificado se o BCC está correcto e, nesse caso, o bloco dos dados da trama recebida é copiado para o buffer pretendido e é confirmada a recepção da trama. Terminando isto, a função llread retorna com o número de caracteres recebidos. Se o BCC estiver errado é pedido o reenvio da mesma trama através do envio de uma trama de rejeição.
● A função llwrite para realizar a transferência de dados necessita de partir a informação em blocos de 255 bytes, que serão inseridos na trama de dados. Deste modo, cada vez que se forma uma nova trama de dados, é necessário alterar o valor do campo C de forma a respeitar as definições do protocolo.
No caso de o receptor receber incorrectamente a trama de dados, deve enviar uma trama de rejeição, de modo a que o transmissor envie novamente essa trama. Fazendo isto num total de 5 vezes, após as quais a função llwrite retorna com um erro.
No caso de os dados serem correctos, verifica se já se enviou todos os dados, que em caso afirmativo retorna o numero de bytes escritos, em caso negativo recomeça todo o processo de construção de tramas.
● A função llclose, tal como a função llopen, também segue caminhos distintos conforme seja chamada no emissor (llclose_t) ou no receptor (llclose_r). No caso de ser chamada no emissor, esta envia uma trama DISC, para avisar o receptor que não tem mais nada a enviar, fazendo isto num total de 3 vezes. Caso a função llclose_r receba a trama DISC, simplesmente envia outra trama DISC para o emissor, que responde com uma trama UA, terminando assim a comunicação lógica.
APLICAÇÃO
Para testar-mos o protocolo desenvolvido criamos duas aplicações, uma para a transmissão e outra para a recepção, que fazem uso das funções desenvolvidas anteriormente (llopen, llread, llwrite e llclose).
O transmissor - o programa começa por abrir o ficheiro a transmitir, Posteriormente chama a
função llopen para ser estabelecida a comunicação, após o estabelecimento desta é chamada a função llwrite que fica encarregue de verificar se enviou o ficheiro completo. Finalmente é chamada a função llclose para terminar a ligação lógica.
O receptor – Este começa por criar o ficheiro para onde vão ser guardados os bytes recebidos.
Posteriormente chama a função llopen para estabelecer a ligação lógica e chama a função llread que vai ler os bytes para o buffer, até receber uma trama DISC, após a qual chama a função llclose para terminar a ligação lógica.
ENSAIO/ TESTE
Para testar o protocolo foi transferido um ficheiro “PDF” entre dois computadores, com sucesso. Também se desligou o cabo a meio da ligação, voltando a ligar dentro dos limites de tempo, tendo a transferência prosseguido normalmente e com sucesso.
ANÁLISE
Com este protocolo de ligação lógica RS232, foram atingidos os objectivos que eram propostos, isto é, fazer uma comunicação entre dois DTE’s sem erros e á prova de falhas no nível físico (cabo).
Porém existe sempre a possibilidade de erros não serem detectados, pois pode acontecer num determinado octeto de dados um bit estar errado, e o XOR resultar igual, ou seja, o XOR pode não ser afectado com a mudança de um determinado bit, num determinado octeto.
Uma maneira de aumentar a fiabilidade da transmissão passaria, a nosso entender, por introduzir mais octetos de controlo BCC intercalados de n em n caracteres de dados, por forma a “apertar a malha” de detecção de erros, porém isso traria o inconveniente de aumentar o overhead.
Uma outra limitação do protocolo é o tamanho máximo do campo de dados que é de 255 octetos, uma vez que só dispomos de um carácter de 8 bits para definir o comprimento:
1111 1111 (binário) = 255 (decimal). A solução seria introduzir um segundo carácter para o comprimento. 1111 1111 1111 1111 (binário) = 65 535 (decimal). Porém o inconveniente seria o aumento exponencial da probabilidade de erro, pois o BCC de dados passaria a abranger não 255, mas 65 535 caracteres.
O uso de um tipo de comunicação assíncrona em vez da síncrona traz a desvantagem de um maior overhead devido aos start e stop bit, além de haver o probabilidade de dessincronização, caso haja uma longa sequência de zeros ou uns, porém, em relação à comunicação síncrona, têm a vantagem de ser mais simples e barata e não necessitar de uma linha extra para transmitir o sinal de relógio.
Este tipo de comunicação RS232 não se aconselha para ambientes industriais visto utilizar transmissão não diferencial (tensões em relação a uma terra comum), logo é mais susceptível ao ruído. Também apresenta uma baixa capacidade de transmissão (bit rate ≤ 20 Kb/s) e limitações em relação à distância máxima possível (≤ 15 mts).
Outro grande inconveniente é que só pode interligar dois terminais (comunicação ponto a ponto).
Para ultrapassar estes obstáculos poderíamos utilizar o protocolo RS422 (bit rate ≤ 10 Mb/s e distância máxima do cabo ≤1.5 kms) ou o RS485, já que usam a transmissão diferencial, maior resistência ao ruído e possibilidade de interligação entre vários terminais em simultâneo.
