LEEC – Ramo APEL

Redes de Computadores
4ºano, 2ºsemestre - 2005/ 06

PROTOCOLO DE COMUNICAÇÃO
SÉRIE RS-232

Realizado por:
Amândio Pereira………...010503121
Carlos Daniel…………….050503245
Redes de Computadores

Í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

2
Redes de Computadores

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.

3
Redes de Computadores

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.

4
Redes de Computadores

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

5
Redes de Computadores

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.

6
Redes de Computadores

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.

7
Redes de Computadores

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.