Implementação Do Protocolo TCP/IP para Sistemas de Intrumentação

UNIVERSIDADE FERDERAL DO RIO GRANDE DO SUL
INSTITUTO DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM COMPUTAO
Implementao do Protocolo TCP/IP

para Sistemas de Instrumentao
por
ROBERTO SCHNHOFEN RIBEIRO
Trabalho de concluso submetido avaliao,

como requisito parcial para a obteno do
grau de Mestre em Informtica
Prof. Luigi Carro

Orientador
Porto Alegre, abril de 2002.
CIP CATALOGAO NA PUBLICAO
Ribeiro, Roberto Schnhofen

Implemetao do Protocolo TCP/IP para Sistemas de
Instrumentao / por Roberto Schnhofen Ribeiro. Porto Alegre:
PPGC da UFRGS, 2002.
75 p.: il.+disquete 3,5
Trabalho de Concluso (mestrado) Universidade Federal do Rio
Grande do Sul. Programa de Ps Graduao em Computao, Porto
Alegre, BR RS, 2002. Orientador: Carro, Luigi
1.TCP/IP.2.FPGA.3.SASHIMI.4.ASIP.I.Carro, Luigi.II.Ttulo.
UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

Reitora: Profa. Wrana Panizzi
Pr-Reitor de Ensino: Prof. Jos Carlos Ferraz Hennemann
Pr-Reitor Adjunto de Ps-Graduao: Prof. Jaime Evaldo Fensterseifer
Diretor do Instituto de Informtica: Prof. Philippe Olivier Alexandre Navaux
Coordenador do PPGC: Prof. Carlos Alberto Heuser
Bibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro
Agradecimentos
Agradeo a Companhia Estadual de Energia Eltrica, na pessoa do Eng. Roberto Silva
Dias, ento chefe da Diviso Tcnica da Distribuio, pela boa vontade demostrada,
bem como pelo auxlio prestado, quando da minha inteno de desenvolver o presente
trabalho. Agradeo tambm ao professor Dr. Luigi Carro da Universidade Federal do
Rio Grande do Sul, meu orientador, sem o qual certamente este trabalho no teria a
qualidade que apresenta. Por fim agradeo a valiosa contribuio prestada pelo MSc.
Jlio Carlos Balzano de Mattos, com seu trabalho e dicas importantes, durante a fase de
desenvolvimento prtico do presente trabalho.
Sumrio
Lista de Abreviaturas............................................................................................... 6
Lista de Figuras .......................................................................................................... 8
Lista de Tabelas ......................................................................................................... 9
Resumo ........................................................................................................................ 10
Abstract ....................................................................................................................... 11
1 Introduo .............................................................................................................. 12
1.1 O Estgio Atual da Pesquisa Mundial .................................................................. 14
1.2 O Ambiente de Aplicao ...................................................................................... 15
1.3 Enfoque do Trabalho ............................................................................................. 18
1.4 Organizao do Trabalho ...................................................................................... 20
2 O TCP/IP Implementado em C ....................................................................... 21

2.1 O Padro NE2000 ................................................................................................... 22
2.1.1 Interface de Rede ................................................................................................... 23
2.1.2 Microprocessador Interno...................................................................................... 23
2.1.3 Memria Local ...................................................................................................... 24
2.1.4 Portas de E/S e Registradores................................................................................ 25
2.2 O Cdigo Pingador ................................................................................................. 31
2.2.1 O Utilitrio PING .................................................................................................. 32
2.2.2 O Hardware de Rede.............................................................................................. 33
2.2.3 Recepo de Dados da Rede.................................................................................. 35
2.2.4 Envio de Dados para a Rede.................................................................................. 36
2.2.5 O Protocolo............................................................................................................ 37
2.2.6 Soma de Verificao.............................................................................................. 38
2.2.7 A Resposta ARP .................................................................................................... 38
2.2.8 A resposta ICMP ................................................................................................... 38
2.3 Funes Auxiliares.................................................................................................. 39
2.3.1 O Clculo de Soma de Verificao ....................................................................... 39
2.3.2 Funo de Inverso MSB LSB ........................................................................... 40
2.3.3 Funo de Temporizao....................................................................................... 41
2.3.4 Funo de Soma de 32 Bits ................................................................................... 42
2.4 O Padro Ethernet ................................................................................................. 43
2.4.1 Ethernet no CI Controlador de Rede ..................................................................... 44
5
2.4.2 A Implementao do Protocolo ............................................................................. 45
2.5 O Protocolo ARP (Address Resolution Protocol) ................................................ 46
2.5.1 A Resposta ARP .................................................................................................... 46
2.5.2 A gerncia do cache ARP...................................................................................... 48
2.6 O Protocolo IP (Internet Protocol) ....................................................................... 50
2.6.1 As Simplificaes Utilizadas................................................................................. 51
2.6.2 A Implementao do Protocolo IP ........................................................................ 52
2.6.3 O Protocolo ICMP (Internet Control Message Protocol) ...................................... 53
2.6.4 A Implementao do Protocolo ICMP .................................................................. 54
2.7 O Protocolo TCP (Transmission Control Protocol) ............................................ 55
2.7.1 Simplificaes Utilizadas no TCP......................................................................... 56
2.7.2 A Mquina de Estados TCP .................................................................................. 57
2.7.3 O Cdigo TCP ....................................................................................................... 58
3 A Gerao de um ASIP ...................................................................................... 60

3.1 A Opo por um Processador Dedicado............................................................... 60
3.2 A Ferramenta SASHIMI ....................................................................................... 62
3.3 A Implementao.................................................................................................... 64
4 Concluso ................................................................................................................ 70
4.1 Desenvolvimentos Futuros ..................................................................................... 71
Anexo programa fonte em C (em disquete)

Bibliografia ................................................................................................................ 73
Lista de Abreviaturas
API
application programming interface
ARP
address resolution protocol
ASIP
application specific instruction set processor
AT
advanced technology
BIOS
basic input output system
CEEE
Companhia Estadual de Energia Eltrica
CI
circuito integrado
CRC
ciclic redundant check
CSMA/CD
carrier sense multiple access / collision detection
DMA
direct memory access
DOS
disc operating system
DSP
digital signal processor
E2PROM
electricaly erasable programmable read only memory
E/S
entrada / sada
FIFO
first in first out
FPGA
field programmable gate array
FTP
file transfer protocol
GE
General Electric
HTML
hiper text markup language
HTTP
hiper text transfer protocol
Hz
Hertz
ICMP
internet control message protocol
IEC
International Electrotechnical Comission
IEEE
Institute of Electrical and Electronics Engeneers
IP
internet protocol
IRQ
interrupt request
ISO
International Organization for Standartization
ISA
Industry Standard Architecture
LAN
local area network
LSB
least significant byte
MAC
media access control
MSB
most significant byte
MTU
maximum transfer unit
7
OSI
open systems interconnection
PC
personal computer
PING
packet internet groper
POP
post office protocol
PPP
point to point protocol
RAM
random access memory
RARP
reverse address resolution protocol
RISC
reduced instruction set computing
RFC
request for comments
SASHIMI
system as software and hardware in microcontrolers
SFD
start of frame delimiter
SMTP
simple mail transfer protocol
TCP
transmission control protocol
UART
universal assincronous receiver transmiter
UDP
user datagram protocol
VHDL
VHSIC hardware description language
WAN
wide area network
Lista de Figuras
FIGURA 1.1 Sistema de comunicao com TCP/IP................................................... 13
FIGURA 1.2 Protocolos do centro de operao. ......................................................... 17
FIGURA 1.3 Encapsulamento de protocolos assncronos........................................... 18
FIGURA 2.1 - Comparao entre os modelos OSI e TCP/IP. ....................................... 21
FIGURA 2.2 Arquitetura da interface de rede. ........................................................... 23
FIGURA 2.3 Dados adicionados e removidos do quadro. .......................................... 23
FIGURA 2.4 Memria local da interface de rede. ...................................................... 24
FIGURA 2.5 Portas de E/S da interface de rede. ........................................................ 25
FIGURA 2.6 - Formato da mensagem de eco (ICMP)................................................... 33
FIGURA 2.7 Fluxo da rotina de tratamento de interrupes. ..................................... 34
FIGURA 2.8 Fluxo da rotina BuscaPct(). ................................................................... 35
FIGURA 2.9 Fluxo da rotina ExistePct(). ................................................................... 36
FIGURA 2.10 Fluxo da rotina EnviaPct()................................................................... 37
FIGURA 2.11 Fluxo da rotina de clculo de soma de verificao.............................. 40
FIGURA 2.12 Fluxo da rotina de temporizao. ........................................................ 42
FIGURA 2.13 - Cabealho do quadro Ethernet ............................................................. 43
FIGURA 2.14 Fluxo do protocolo Ethernet ................................................................ 45
FIGURA 2.15 - Formato dos dados dos protocolos ARP. ............................................. 47
FIGURA 2.16 Fluxo da funo de resposta ARP........................................................ 48
FIGURA 2.17 Fluxo da funo de procura na tabela ARP. ........................................ 49
FIGURA 2.18 - Formato do datagrama IP ..................................................................... 50
FIGURA 2.19 O fluxograma da rotina IP ................................................................... 52
FIGURA 2.20 - Formato da mensagem ICMP............................................................... 53
FIGURA 2.21 Fluxograma da rotina ICMP ................................................................ 54
FIGURA 2.22 - Formato do cabealho do TCP ............................................................. 55
FIGURA 2.23 Mquina de estados simplificada......................................................... 57
FIGURA 2.24 Fluxo do protocolo TCP. ..................................................................... 59
FIGURA 3.1 Arquitetura do microcontrolador FemtoJava......................................... 63
FIGURA 3.2 Ambiente de teste. ................................................................................. 64
FIGURA 3.3 Troca de dados entre cliente e servidor. ................................................ 65
FIGURA 3.4 Fluxo de sntese do microcontrolador TCP/IP....................................... 68
Lista de Tabelas
TABELA 2.1 Registradores de configurao, pgina 0. ............................................. 25
TABELA 2.4 Configurao do registrador CR. .......................................................... 27
TABELA 2.5 Configurao do registrador ISR. ......................................................... 27
TABELA 2.6 Configurao do registrador IMR......................................................... 28
TABELA 2.7 Configurao do registrador DCR. ....................................................... 28
TABELA 2.8 Configurao do registrador TCR......................................................... 29
TABELA 2.9 Configurao do registrador TSR. ........................................................ 29
TABELA 2.10 Configurao do registrador TCR....................................................... 29
TABELA 2.11 Configurao do registrador TSR. ...................................................... 30
TABELA 2.12 - Significado dos indicadores no cabealho TCP .................................. 56
TABELA 3.1 Conjunto de instrues implementadas no SASHIMI.......................... 64
TABELA 3.2 Comparao de cdigos fonte............................................................... 66
TABELA 3.3 Comparao de cdigos executveis. ................................................... 67
TABELA 3.4 Resultados da sntese do hardware ....................................................... 68
10
Resumo
Baseado na tecnologia de interligao de redes, este trabalho apresenta uma proposta de
conexo de dois sistemas com processamento prprio com o intuito de troca de
informaes, utilizando a pilha de protocolos TCP/IP.
Este sistema ser empregado em ambientes de controle industrial, permitindo o envio de
informaes do servidor de dados para o cliente. Os dados so constitudos de leituras
feitas em equipamentos de campo, apresentando ao cliente remoto, medies dos mais
diversos tipos. Por outro lado, o cliente poder enviar comandos aos equipamentos de
campo visando o telecontrole.
Como ponto de partida para a elaborao do trabalho prtico, foi utilizado o ambiente
de controle do sistema de potncia da companhia energtica do estado do Rio Grande do
Sul (CEEE). Um microcomputador com um browser acessa, atravs de uma rede local,
os equipamentos controlados, que podero ser qualquer tipo de equipamento de campo
empregado em subestaes de energia eltrica, como disjuntores, transformadores ou
chaves.
Para permitir o acesso remoto de tais equipamentos, foi elaborado um servidor de dados
constitudo de um controlador de rede do tipo Ethernet e um microcontrolador de
aplicao especfica que se encarrega do processamento da pilha de protocolos. O
controlador Ethernet utilizado um circuito integrado dedicado comercial, que executa
o tratamento dos sinais de nvel fsico e de enlace de dados conforme o padro IEEE
802.2. O processador TCP/IP, enfoque principal deste trabalho, foi elaborado atravs da
linguagem de programao C, e a seguir traduzido para o Java, que o ponto de partida
para a ferramenta SASHIMI, de gerao da descrio em VHDL do microcontrolador
de aplicao especfica utilizado. O processador TCP/IP encarrega-se da aquisio de
dados do equipamento de campo, do processamento da pilha de protocolos TCP/IP, e do
gerenciamento do controlador Ethernet.
A partir desta descrio VHDL, foi sintetizado o hardware do microcontrolador em um
FPGA, que juntamente com o software aplicativo, tambm fornecido pela ferramenta
utilizada, desempenha o papel de processador TCP/IP para o sistema proposto.
Neste ambiente, ento, o cliente localizado no centro de operao, acessa atravs de um
browser o equipamento de campo, visando obter suas medies, bem como enviar
comandos, destacando o aspecto bidirecional para a troca de dados e a facilidade de
conexo de dois sistemas heterogneos.
Este sistema pretende apresentar baixo custo de aquisio e de instalao, facilidade de
interconexo local ou remota e transparncia ao usurio final.
Palavras Chave: TCP/IP, FPGA, SASHIMI, ASIP.
11
TITLE: TCP/IP PROTOCOL IMPLEMENTATION TO INSTRUMENTATION

SYSTEMS
Abstract
Based on networks interconnection technologies, this work presents a proposal of
connection between two processing systems, aiming at information exchange employing
the TCP/IP protocol stack.
This system will be applied in the industrial control environments, allowing the
information exchange between the data server and the client. The data is composed of
readings made from field equipment, presenting to the remote client several kinds of
measurements. On the other hand, the client can send commands to the field equipment
implementing remote control.
As a starting point to the elaboration of this work, the control environment of the Power
Company of Rio Grande do Sul (CEEE) was utilized. A microcomputer is provided
with browser access, through the local network, to the controlled equipment, which can
be any kind of field equipment applied in power stations, as circuit breakers,
transformers or switches.
In order to allow the remote access of this equipment, a data server build with an
Ethernet network controller and an application specific microcontroller was developed.
The microcontroller does all the processing of the protocol stack. The Ethernet
controller employed is a commercial dedicated integrated circuit, which executes the
signal treatment on the physical and data link levels as the IEEE 802.2 standard. The
TCP/IP processor was the main goal of this work, and was developed with the C
language, and next translated to Java, which is the starting point to the VHDL
generation tool SASHIMI, to describe the used application specific microcontroller. The
TCP/IP processor is responsible for all data acquisition of field equipment, as well as
the TCP/IP stack processing and Ethernet controller management.
From the VHDL output description provided by the SASHIMI tool, the hardware of the
dedicated microcontroller was synthesized in a FPGA, with its application software,
also supplied by the tool, which plays the role of TCP/IP processor to the proposed
system.
In this environment, the client is placed in the operation center, and has access to the
field equipment through the browser. This way, it can check the status and send
commands, showing the two way path and the easiness of connection between two
heterogeneous systems.
This system is intended to present low cost of acquisition and installation, easy
interconnection between local and remote equipment and transparency of use to the end
user.
Keywords: TCP/IP, FPGA, SASHIMI, ASIP.
12
1 Introduo
A necessidade de comunicao est pressionando a pesquisa, cada vez mais, a elaborar

solues simples, econmicas e principalmente eficientes, de forma a satisfazer uma
necessidade bsica do ser humano: a troca de idias com seus semelhantes de uma
forma abrangente e o mais natural possvel, ou seja, sem os obstculos muitas vezes
impostos pela complexidade tecnolgica. O desenvolvimento destas solues
atualmente caminha a passos largos para o emprego de meios de troca de informao
que, de uma maneira ou de outra, atinjam praticamente toda a populao mundial,
levando em um curto espao a no se conceber mais uma situao ou local onde os
meios de troca de informao com o mundo exterior sejam precrios ou mesmo
inexistentes.
Neste contexto de exigncias do mercado de troca de informaes, surge no final da
dcada de 70 uma rede de computadores, que, inicialmente experimental, tornou-se
rapidamente um padro mundial para a troca de dados e mensagens. Essa rede,
conhecida como Arpanet, foi a princpio fortemente incentivada e financiada pelo
governo dos Estados Unidos da Amrica do Norte, e ento compartilhada entre
instituies militares americanas e algumas universidades. Ao longo dos anos, o custo
dos computadores pessoais foi fortemente reduzido, e as conexes a esta rede em muito
facilitada ao usurio comercial e particular, produzindo a exploso da mesma pelo
mundo afora, quando j era conhecida como Internet [TAN 97]. Uma exigncia feita
para a interligao na rede mundial: a utilizao da pilha de protocolos universalmente
padronizada para acesso, o Transmission Control Protocol / Internet Protocol (TCP/IP).
Um dos motivos pelo qual a Internet fez tanto sucesso em detrimento de tantos outros
padres ento existentes pelo fato da tecnologia empregada ter pelo menos dez anos
de testes e aperfeioamentos. Vindo ao encontro desta vantagem, de acordo com
Douglas E. Commer [COM 98]: Utilize os padres dos protocolos existentes sempre
que estes padres se aplicarem; crie novos padres apenas quando os padres existentes
forem insuficientes e esteja apto para utilizar novos padres quando eles se tornarem
disponveis e proporcionarem uma funcionalidade equivalente. Pelo at aqui exposto,
fica flagrante que qualquer tentativa de conexo para troca de informao entre duas ou
mais entidades quaisquer, atualmente, dever passar por uma anlise sria do ponto de
vista tcnico econmico, convergindo para a utilizao, de alguma forma, dos padres
j amplamente aceitos e disponveis.
Muitos aspectos tcnicos tambm levam o projetista a sempre avaliar com seriedade a
possibilidade de utilizao da pilha TCP/IP em novos projetos, e um item fundamental
a maturidade fornecida pelos protocolos, onde anos de pesquisa e desenvolvimento
forneceram ao usurio uma pilha bastante funcional e estvel do ponto de vista do
roteamento de pacotes de dados, desde pequenas distncias at a distncias continentais.
Para qualquer outra tecnologia que se considere em implementar, os problemas de
roteamento, entre outros, a serem enfrentados j foram h muito considerados e
13
resolvidos no TCP/IP, no grande laboratrio de testes da Internet, tornando-o uma
soluo bastante atraente.
A proposta do trabalho aqui apresentado, viabilizar a conexo de dois sistemas
heterogneos utilizando a pilha de protocolos do TCP/IP, baseado na infra-estrutura j
padronizada e bastante difundida das redes locais e globais (LAN Local Area
Network, WAN Wide Area Network). Para atingir tal objetivo foi desenvolvido um
hardware especfico que se encarrega do estabelecimento da conexo via rede e da troca
de dados entre os sistemas cliente e servidor. O hardware um processador para
aplicao especfica que possui a qualidade de gerenciar um controlador de rede do
padro Ethernet e processar os pacotes que chegam da rede, gerando uma resposta
adequada, segundo a pilha de protocolos. Este processador foi implementado com a
utilizao de um FPGA (Field Programmable Gate Array). Outra caracterstica
importante deste processador a sua integrao, uma vez que todo o gerenciamento do
protocolo ser diretamente inserido no hardware, liberando recursos de memria e
processamento. A figura 1.1 a seguir ilustra de forma simplificada o sistema proposto.
Fonte de
Dados
Processador
TCP/IP
Controlador
Ethernet
Rede LAN,
WAN
Cliente
FIGURA 1.1 Sistema de comunicao com TCP/IP.
Uma aplicao do sistema a medio, superviso e controle do sistema de potncia

atualmente sendo implantado na companhia energtica do estado (CEEE Companhia
Estadual de Energia Eltrica). Neste caso, a fonte de dados ser a medio de um
determinado equipamento de campo de uma subestao de energia eltrica, que possui
um conjunto completo de medidas disponvel para o usurio, como por exemplo tenso
e corrente trifsica, e todas as medidas derivadas destas seis medidas primrias, por
exemplo, potncia ativa, aparente e reativa, fator de potncia, energia, entre outras.
Como fonte de dados podemos colocar tambm o estado dos diversos equipamentos de
campo que constituem a subestao como disjuntores, chaves e transformadores, e estes
estados so definidos como aberto ou fechado, ligado ou desligado e assim por diante.
Acrescente-se a isto o comando destes equipamentos, que em ltima anlise so dados
que fluem no sentido inverso dos anteriormente mencionados.
Neste caso especfico, o cliente um computador qualquer executando um sistema
operacional como o Windows ou Linux, que possua um navegador Internet com as
facilidades do protocolo TCP/IP. Ligado Internet ou a sua Intranet, Conecta-se ao
sistema proposto, que estar localizado diretamente junto ao mdulo em questo ou
equipamento de campo. De acordo com o grau de segurana ou alcance que se queira
atingir ser escolhida a rede adequada. Como regra geral, se a segurana fator
determinante, ento uma rede privada e dedicada dever ser utilizada (Intranet). Se, por
outro lado, o alcance dos dados mais importante ento a Internet a escolha adequada.
Neste ponto um controlador Ethernet extrai da rede as informaes destinadas ao
sistema, que foram originalmente enviadas pelo cliente, e as remete ao processador
TCP/IP, que as processa e d o destino adequado. Se existirem dados que devam ser
14
enviados ao equipamento de campo, estes sero formatados de maneira adequada e em
seguida remetidos. Esta formatao, simplificadamente, poder ser a serial assncrona, a
qual amplamente utilizada em sistemas mais simples.
De forma semelhante, os dados que devam ser enviados do campo para o cliente
percorrem o sistema no sentido inverso. O processador TCP/IP se encarrega de todos os
processos que so necessrios antes e durante a conexo fim-a-fim entre cliente e
servidor de dados. Esta conexo estabelecida no nvel de transporte de dados com o
protocolo TCP, conforme ser visto mais adiante, e apresenta uma srie de processos de
troca de pacotes entre cliente e servidor, antes de se estabelecer a fase de troca de dados
propriamente dita.
A partir do ponto de estabelecimento da conexo os dados fluem em ambos sentidos,
facilitando o envio de dados do servidor para o cliente, bem como o envio de
requisies ou comandos do cliente para o servidor.
Com a inteno de alocar o sistema TCP/IP junto aos equipamentos de campo, e
portanto sujeito s intempries, foi proposto que o resultado final deve ser o mais
simples e robusto possvel. Com isto em mente, o hardware resultante deve ser pequeno,
leve e apresentar um pequeno consumo de energia, simplificando assim, sua aquisio,
instalao e manuteno.
Para atingir os objetivos propostos o trabalho aqui apresentado seguiu um fluxo de
tarefas, conforme a seguir:
1. Elaborao do software que implementa a pilha de protocolos TCP/IP.
2. Descrio do hardware de um microcontrolador ASIP com auxlio da ferramenta
SASHIMI.
3. Simulao do hardware com a ferramenta MAX + Plus II e levantamento de
alguns dados de desempenho.
1.1 O Estgio Atual da Pesquisa Mundial

As empresas da rea de fabricao de CIs, muitas vezes fomentadas por empresas
consumidoras de tecnologia, esto dedicando grandes esforos no sentido de
desenvolver solues simples e eficientes na rea de comunicao de dados sobre a
Internet.
Um exemplo neste sentido, a pesquisa promovida pela Daimler-Benz Research and
Technology Center dos Estados Unidos que colocou um grupo de pesquisadores no
desenvolvimento de solues de comunicao via Internet para automveis [JAM 98].
A pesquisa visa contemplar os veculos com um produto completo e acabado, portanto
muito est sendo investido no sentido de resolver problemas inerentes ao projeto. Trs
pontos fundamentais esto em desenvolvimento: o meio de comunicao sem fio, a
arquitetura do sistema e a interface com o usurio.
15
Outro aspecto da pesquisa atual o desenvolvimento de CIs que integram, cada vez
mais, as funes sempre executadas por software. Um exemplo disto o CI
desenvolvido pela Osicom Technologies que integra em uma pastilha a interface
Ethernet juntamente com os protocolos TCP, UDP, RARP, ICMP, HTTP, POP, SMTP
e FTP chamado de system on silicon [VAR 98].
Algumas outras implementaes da pilha de protocolos TCP/IP notveis por sua
simplicidade e economia de recursos so as desenvolvidas com os microcontroladores
da Microchip [LOE 99], da Atmel [LIG 2000], e da Scenix [SCE 2000]. As trs
implementaes colocam a pilha de protocolos em software, o que os tornam um pouco
lentos e limitados, devido aos recursos escassos de memria e processamento, mas do
ponto de vista de custo de fabricao, consumo de potncia e de tamanho fsico, so
incomparveis.
O CI mais notvel sob o aspecto de conectividade com a grande rede , sem dvida, o
S7600A da Seiko Instruments Inc. [SEI 2001], o qual possui implementado em
hardware os protocolos TCP/UDP para o nvel de transporte, o protocolo IP para o nvel
de rede e para o nvel de enlace de dados utiliza o PPP. A parte fsica fica a cargo do
projetista atravs de uma UART (Universal Assynchronous Receiver Transmitter)
interna. Com grande parte da pilha TCP/IP implementada em hardware, a parte de
aplicao fica a cargo de um pequeno microcontrolador externo, que pode ser escolhido
dentre vrios modelos e marcas de possvel utilizao com a interface disponvel no CI
da Seiko.
O S7600A implementa a tecnologia conhecida por iReady, a qual apresenta ao usurio
uma extensa lista de funes (API Application Programming Interface) para a troca de
dados e gerenciamento do circuito como um todo, independente de sistema operacional,
sendo fornecida em linguagem C.
Outro circuito integrado interessante nesta rea o SC12 IPC@CHIP fabricado pela
empresa Beck [BEC 2001], este CI encapsula, em uma nica pastilha, um processador
80186, 512 kB de memria RAM (Random Access Memory), 512 kB de memria Flash
e um controlador Ethernet conforme o padro fsico 10Base T [SPU 2002]. Este sistema
executa uma verso simplificada do sistema operacional DOS (Disk Operating System),
e apresenta ao usurio uma ampla gama de rotinas de BIOS (Basic Input Output
System), que alm das rotinas de uso geral, apresentam funes de controle e
manipulao do ambiente de rede com o conjunto de protocolos TCP/IP.
1.2 O Ambiente de Aplicao

Baseado na amplitude da aplicabilidade do protocolo de comunicao de dados TCP/IP,
qualquer sistema que necessite a troca de dados ponto-a-ponto ou ponto-multiponto, que
utilizar tal pilha ter, a priori, uma ampla gama de conectividade entre sistemas
heterogneos, bem como enormes facilidades de conexo fsica em rede. Baseado no
aspecto de que embora no padronizado por RFCs (Request for Comments), a camada
fsica de ambientes que se utilizam da pilha TCP/IP possuem opes de conectividade
bastante difundidas e adotadas de fato como padres industriais. Exemplos neste sentido
podem ser o padro fsico Ethernet, bem como a conexo serial assncrona com seus
protocolos de nvel de enlace de dados bem definidos e mundialmente aceitos.
16
Com o canal de transporte de dados entre sistemas heterogneos resolvido atravs da
aplicao do protocolo TCP/IP e seu nvel fsico, resta apenas a definio da camada de
aplicao, que embora bastante dependente da aplicao fim pode, de forma
simplificada, ser utilizado algum protocolo j em uso no Mundo Internet, como por
exemplo o HTTP (Hiper Text Transfer Protocol).
O ambiente de aplicao proposto por este trabalho foi o de um sistema de comunicao
de dados utilizado para o telecontrole e a telemedio de sistemas eltricos de potncia,
onde o nmero e a complexidade dos pontos de controle e medio possuem
caractersticas apropriadas s restries impostas pelo protocolo TCP/IP.
O sistema eltrico, de maneira geral, no possui caractersticas de tempo real, ou seja, o
tempo de resposta do ambiente como um todo no crtico, sendo observveis
intervalos de tempo entre comando e resposta na casa de segundos, tipicamente entre 3
a 10 segundos. Embora tais tempos no sejam desejveis, so tolerveis na aplicao em
que este trabalho se prope, vindo ao encontro com a caracterstica no determinstica
do protocolo TCP/IP.
Outro aspecto a crescente demanda e gerao de informaes por parte dos
equipamentos empregados no sistema de controle e proteo eltrico. Com o advento da
digitalizao dos rels de proteo, a quantidade de dados analgicos e digitais gerados
por tais dispositivos vem crescendo vertiginosamente ao longo do tempo. Como
exemplo, pode-se citar os rels de proteo eltrica fornecidos pela General Electric
(GE) onde se encontram a disposio do usurio dezenas de milhares de informaes
diferentes [GEN 2001]. Baseado na quantidade de dados disponvel, de se supor que a
largura de banda do canal de comunicao de dados utilizado por tais equipamentos
deva ser bastante larga. Neste particular, o protocolo TCP/IP fornece caractersticas de
velocidade de troca de dados baseado principalmente na camada fsica escolhida.
A confiabilidade dos dados transportados outro ponto que deve ser levado em conta,
porque a aplicao no tele controle de sistemas eltricos de potncia pressupe troca de
dados com alta qualidade, tendo em vista que o processo extremamente crtico sob o
ponto de vista de segurana pessoal. Neste particular, esto padronizados vrios
esquemas de controle e correo de erro pela pilha TCP/IP em diversas camadas,
redundando na troca de dados extremamente confivel.
No ambiente de aplicao de controle de sistemas de potncia existem atualmente vrios
protocolos de comunicao de dados em utilizao, com normatizao internacional.
Como exemplo, pode-se citar o protocolo IEC 870-101, baseado na norma de mesmo
nome [INT 95], e o protocolo DNP 3.0, tambm baseado nesta norma internacional,
embora incompatveis entre si. Protocolos industriais esto surgindo neste ambiente,
como o Modbus [MOD 96] lanado originalmente pela empresa Modicon, e o Profibus
[PRO 99], alm de vrios outros protocolos proprietrios de menor expresso.
17
FIGURA 1.2 Protocolos do centro de operao.
Neste ambiente com tantas possibilidades de protocolos de comunicao de dados, o

papel do gateway, ou seja, o tradutor de protocolos, de fundamental importncia.
Como ilustrado na figura 1.2, existe um protocolo de comunicao entre o equipamento
de campo, tipicamente um rel de proteo eltrica digital, e a unidade terminal remota,
que executa o papel de tradutor para o protocolo de comunicao utilizado pelo centro
de operao. Podem ser encontrados casos onde, dentro da subestao, equipamentos de
fabricantes diferentes disponibilizem protocolos diferentes para a unidade terminal
remota, que dever concentr-los e traduzi-los adequadamente.
Existem equipamentos de proteo eltrica que esto sendo fornecidos com o protocolo
de transporte TCP/IP e a camada fsica Ethernet [GEN 2001], mas isto ainda uma
aproximao muito recente e pouco difundida, sendo ainda muito empregados os
protocolos especficos da rea eltrica como o DNP e o IEC, bem como os industriais
Modbus ou Profibus.
Neste ambiente, o encapsulamento de algum protocolo serial dentro da pilha TCP/IP
uma possibilidade bastante poderosa, tendo em vista a facilidade de conexo de
equipamentos diversos. Um exemplo o encapsulamento de um dos dois principais
protocolos da rea de controle eltrico (DNP e IEC), que utilizam no nvel fsico a
transmisso de dados do tipo serial assncrono com bit de incio e de parada. Neste caso,
o protocolo serial assncrono diretamente colocado na camada de aplicao da pilha
TCP/IP, sendo desencapsulado do outro lado, como mostra a figura 1.3 a seguir.
Considerando-se o ambiente de comunicao de dados Ethernet como serial e sncrono,
ento os bits de incio e de parada, utilizados pelos protocolos originais, no so
necessrios, apresentando um ganho no desempenho.
18
Protocolo Assncrono
Protocolo Assncrono
TCP
TCP
IP
IP
Enlace de Dados
Fsico
Interconexo
Enlace de Dados
Fsico
FIGURA 1.3 Encapsulamento de protocolos assncronos.
O encapsulamento do protocolo serial pode ser feito por um equipamento externo, ou

localizar-se diretamente no equipamento de campo. Este trabalho prope um sistema
que poder ser diretamente implementado no equipamento de campo, encapsulando o
protocolo nativo ou proprietrio na pilha TCP/IP, residindo no encapsulamento a grande
vantagem desta abordagem, porque a partir deste momento, a conectividade, antes
restrita por padres pouco difundidos seno completamente proprietrios, passam a
desfrutar das vantagens da padronizao e amplitude de emprego do TCP/IP.
O protocolo encapsulado na camada de aplicao poder ser algum de utilizao
restrita, como tipicamente o so os protocolos utilizados na rea de controle eltrico,
bem como algum protocolo disponvel na pilha TCP/IP, bem mais difundidos,
facilitando desta forma o lado cliente do sistema.
Um exemplo neste sentido o protocolo HTTP, que poder ser empregado no lado
cliente utilizando-se to somente um navegador Internet como o Internet Explorer ou o
Netscape Navigator.
1.3 Enfoque do Trabalho

A inteno do trabalho aqui exposto a conexo de dois sistemas com processamento
prprio, atravs da utilizao da infra estrutura simples, econmica e acessvel fornecida
pelo mundo Internet. interessante notar que este mundo no se restringe apenas
rede fsica, mundialmente disponvel ao usurio comum, o que por si s possui um
grande valor agregado, mas principalmente seu ponto notvel a sua padronizao,
mundialmente aceita e utilizada.
Sob este enfoque, tal sistema de troca de informao, alm da aplicao proposta por
este trabalho, ser til e plenamente aplicvel em pequenas redes locais, muitas vezes
isoladas da grande rede mundial, onde podem ser utilizados equipamentos de
interconexo de rede como modems ou hubs, com a inteno de conexo entre cliente e
servidor visando a superviso e/ou controle de pequenos processos industriais,
comerciais ou at mesmo domsticos. Devido facilidade de conexo com a rede
mundial, este sistema pode ser tambm empregado em situaes em que grandes
distncias devam ser vencidas, como no caso tpico de viagens, onde o cliente se
19
encontra em um pas e o servidor em outro. Existe tambm a possibilidade de emprego,
conforme j abordado, em sistemas de controle industriais de grande porte, onde os
equipamentos envolvidos so mais robustos e confiveis.
O sistema que executar o papel de cliente na estrutura proposta, ou seja, o consumidor
de dados, por questo de facilidade, poder ser qualquer microcomputador que execute
um sistema operacional que suporte os padres fornecidos pela pilha de protocolos
TCP/IP. No nvel de aplicao ser utilizado um navegador, que utilize o protocolo
HTTP (Hiper Text Transfer Protocol) para apresentao dos dados.
No lado servidor, o sistema aqui elaborado fornecer os dados requeridos pelo cliente,
seguindo, de forma semelhante, os padres estabelecidos pelas diversas RFCs, com o
intuito de tornar o mais simples possvel a interconexo em rede dos lados cliente e
servidor. O desenvolvimento do equipamento servidor ser o objetivo do trabalho aqui
exposto, constituindo-se de alguns CIs (Circuitos Integrados) que, de forma compacta,
simples e econmica, atendero s requisies do cliente.
O desenvolvimento do processador TCP/IP foi feito utilizando-se uma ferramenta de
desenvolvimento de processadores de aplicao especfica, que toma por base o cdigo
desenvolvido em Java e produz o cdigo VHDL (VHSIC hardware description
language) correspondente ao hardware requerido. A ferramenta SASHIMI foi
desenvolvida em um trabalho de mestrado da Universidade Federal do Rio Grande do
Sul [ITO 2000], e fornece um processador especificamente voltado para uma aplicao
descrita em Java, com um conjunto de instrues bastante particular.
Uma simplificao importante utilizada neste ambiente, visando minimizar os recursos
empregados no processador TCP/IP, e em ltima anlise reduzir a rea de silcio
necessria durante a fase de integrao em hardware, implementado somente o lado
servidor no processador. Com este artifcio, grande parte do cdigo e dos recursos
necessrios deixaram de ser utilizados, reduzindo o tamanho do sistema como um todo.
Para tanto, parte-se do princpio que o servidor no ir solicitar uma conexo via rede,
mas aceitar conexes originadas remotamente. E, aps estabelecida a conexo, a troca
de dados poder se tornar bidirecional.
Para atingir tal objetivo, foram executadas as aes, conforme descrito a seguir.
Elaborao de uma base de dados terica, baseado na pesquisa bibliogrfica sobre

os temas Internet, pilha de protocolos TCP/IP, o padro de enlace de dados Ethernet,
circuitos integrados dedicados para o fim de comunicao de dados que utilizam os
diversos padres empregados na grande rede, entre outros temas correlacionados.
Seleo e implementao de uma base de desenvolvimento de hardware constituda

de uma grande rede local e alguns computadores de teste padro PC (Personal
Computer) com sistema operacional DOS, por questo de simplicidade de
desenvolvimento.
Desenvolvimento em linguagem C de uma primeira aproximao do servidor HTTP.
Ajuste e recompilao do software desenvolvido com o fim de servir de fonte para a

ferramenta SASHIMI (system as software and hardware in microcontrollers), que
20
gerar o cdigo VHDL de um processador para aplicao especfica, bem como o
cdigo pertinente.
Prototipao em um FPGA (Field Programmmable Gate Array) do processador e

seu software aplicativo.
O ambiente de desenvolvimento inicial foi escolhido em funo da facilidade de

desenvolvimento em um PC com a utilizao da linguagem C. Desta forma, o hardware
utilizado em rede, chamado Controlador Ethernet, pde ser diretamente acessado,
atravs de seus registradores, resultando em um cdigo mais rpido e eficiente. O
controlador Ethernet um circuito integrado dedicado que se encarrega de todo o
interfaceamento entre o nvel de rede e o nvel fsico, automatizando de forma
acentuada o processo de colocao dos dados no fio. Caso houvesse a opo pela
Linguagem Java, fonte de entrada da ferramenta SASHIMI [ITO 2000], esta facilidade
no seria verificada. Por esta razo, durante a elaborao da traduo do C para o Java,
alguns artifcios foram utilizados quando da necessidade de adequao das
particularidades dos dois sistemas utilizados, a saber o PC e o microcontrolador de
aplicao especfica.
1.4 Organizao do Trabalho

Os captulos restantes sero organizados de forma cronolgica de assuntos, ou seja
conforme foram sendo abordados e desenvolvidos. A ordem apresentada ser como se
segue:
Captulo 2: Este captulo trata da codificao do protocolo com o auxlio da

linguagem C. Sero apresentados aspectos relativos ao padro utilizado nas placas
de rede, com vista implementao da camada de ligao entre o meio fsico e o
nvel de enlace de dados. Ser abordado o protocolo de comunicao que se coloca
no nvel de enlace de dados, e definido pela norma IEEE sob o nmero 802.3, bem
como os principais protocolos da pilha: ARP (Address Resolution Protocol), IP
(Internet Protocol)e o TCP (Transmission Control Protocol). Alm disto ser visto a
primeira aproximao executada em C para verificao de funcionamento e
viabilidade do trabalho, que foi a codificao do protocolo ICMP simplificado com
o utilitrio PING.
Captulo 3: Trata da traduo do cdigo C para Java visando sua utilizao como
entrada na ferramenta SASHIMI, que gerar uma descrio em VHDL de um
processador de aplicao especfica, bem como o software compatvel.
Captulo 4: Trata das concluses retiradas do trabalho desenvolvido e apresenta

algumas possibilidades de desenvolvimentos futuros.
21
2 O TCP/IP Implementado em C
As RFCs que padronizam os protocolos constituintes da pilha TCP/IP definem quatro

camadas de servios de rede, a saber: o nvel de rede / hospedeiro, o nvel de
interligao de redes, o nvel de transporte e o nvel de aplicao. Pode ser traado um
paralelo entre o modelo TCP/IP e o modelo de referncia ISO-OSI [ISO 94] que possui
sete camadas, como apresentado na figura 2.1.
Modelo OSI
7. Aplicao
TCP/IP
Aplicao
6. Apresentao
No esto presentes
no modelo.
5. Sesso
4. Transporte
3. Rede
Transporte
Interligao de redes
2. Enlace de dados
Rede / Hospedeiro
1. Fsica
No esto padronizadas
no modelo.
FIGURA 2.1 - Comparao entre os modelos OSI e TCP/IP.
O primeiro nvel (rede / hospedeiro) no padronizado, fornecendo uma importante

caracterstica do TCP/IP, que a viabilidade de utilizao com diferentes tipos de
hardware de rede local, o que possibilita a interoperabilidade de sistemas heterogneos,
desde que seja vivel a sua conexo de nvel um e dois. A camada seguinte (interligao
de redes) responsvel pela recepo dos pacotes que os hospedeiros injetam na rede e
a sua conseqente entrega na rede de destino, seja ela a prpria rede local onde o
hospedeiro gerador do pacote se conecta, ou uma rede localizada milhares de
quilmetros de distncia tal que, para atingi-la, o pacote dever atravessar dezenas de
redes intermedirias, configurando, neste caso, o roteamento do pacote. Essa camada
pode ser comparada ao servio de correio, onde cartas so postadas, mas nenhuma
garantia de entrega ou mesmo de seqenciamento existe, a nica certeza sobre a
probabilidade da entrega ou descarte do pacote roteado que todo o esforo ser
empenhado pela camada, no sentido de entregar com correo os pacotes a ela
confiados. O protocolo que executa os servios deste camada o Internet Protocol (IP).
A confiabilidade fica a cargo da prxima camada que fornece uma conexo fim-a-fim
entre os hospedeiros fonte e destino da informao a ser trocada, independente de
distncia ou mesmo do nmero de redes intermedirias que devem ser vencidas para
atingi-lo, disponibilizando mecanismos de correo de erros que, a critrio do usurio,
podem ou no serem utilizados. Para um fluxo de bytes fim-a-fim com conexo e
correo de erros, o protocolo a ser utilizado ser o Transmission Control Protocol
(TCP) e, para o caso de no existir a necessidade de alta confiabilidade na troca de
22
dados, ento o User Datagram Protocol (UDP) dever ser utilizado por ser mais
simples que o TCP. Deve-se observar que o ncleo do TCP/IP so exatamente os
protocolos constituintes das camadas de nvel trs e quatro mais alguns outros
protocolos auxiliares a estes dois nveis, alm de algumas aplicaes (nvel sete) de
implementao obrigatria segundo a padronizao [MUR 98].
O primeiro passo para a implementao do sistema a preparao e utilizao do
controlador Ethernet, que se encarregar de todo o protocolo de nvel de enlace de
dados e fsico. Este controlador segue um padro bastante difundido entre os ambientes
de comunicao de dados em rede conhecido por NE2000, simplificando bastante a
conexo dos protocolos de nvel de rede com o cabo de rede.
2.1 O Padro NE2000

Neste item ser analisado o padro NE2000 e o tipo de acesso a dados conhecido por
E/S (entrada e sada), do ponto de vista de sua arquitetura, implementao e utilizao.
Sob o aspecto operacional, este tipo de acesso muito simples, j que no necessita de
hardware adicional, alm do prprio circuito integrado (CI) controlador de rede. Alm
disto, no prev a utilizao de recursos externos, tais como memria ou outros CIs de
funo especfica, simplificando os mtodos de acesso aos dados que chegam e so
enviados via rede.
O padro NE2000 define um modo bsico de acesso aos dados recebidos ou enviados
pelo controlador de rede. Este modo utiliza o barramento de entrada e sada (E/S) do
processador para acessar os dados que chegam e saem atravs da rede. Este tipo de
acesso simples e utiliza somente o hardware j disponvel no CI que implementa as
funes de transmissor/receptor de dados de rede, e a interface com o barramento de
E/S do processador. Os controladores comerciais implementam os barramentos
segundos os formatos ISA ou PCI, onde para efeitos do desenvolvimento prtico do
trabalho foi escolhido o formato ISA, principalmente por sua simplicidade de utilizao.
Atualmente esto disponveis CIs que implementam internamente todas as funes
necessrias ao correto funcionamento em rede segundo o padro NE2000 [NAT 95]
[REA 95] [DAV 97], simplificando a implementao de um dispositivo de interface
entre o hospedeiro e a rede fsica. Do ponto de vista da rede, ou seja, o protocolo de
injeo e extrao dos dados no fio, o padro empregado o IEEE 802.3 [IEE 96]. Do
ponto de vista do driver de dispositivo o padro o NE2000, onde so especificados
registradores de configurao, de acesso aos dados, bem como o protocolo de como
extrair e enviar dados para a interface de rede.
A figura 2.2 apresenta o diagrama em blocos interno do CI controlador de rede, dando
uma noo da sua arquitetura interna. As funes desempenhadas pelos diversos
componentes sero objeto da anlise a seguir.
23
CI NE2000 Compatvel
RAM Local
64 kB
Rede
10Base-T,
10Base-2
Interface
de Rede
IEEE 802.3
Portas de I/O,
Registradores
Barramento
do Host
Processador
Interno
FIGURA 2.2 Arquitetura da interface de rede.
2.1.1 Interface de Rede

A interface de rede responsvel pela adaptao de nvel e codificao dos dados a
serem enviados pela rede, bem como pela decodificao e filtragem dos dados recebidos
desta. Alm disto, este sistema executa todos os procedimentos necessrios ao correto
encaminhamento de pacotes, seguindo o protocolo estabelecido na norma IEEE 802.3
com o tipo de acesso ao meio fsico CSMA/CD (Carrier Sense Multiple Access /
Collision Detection). O prembulo e o CRC (Cyclic Redundant Check) do pacote
Ethernet so automaticamente inseridos nos dados a serem enviados, e retirados dos
pacotes que chegam conforme ilustra a figura 2.3.
Prembulo
SFD
Destino
Origem
Tipo
Dados
CRC
62 bits
2 bits
6 bytes
6 bytes
2 bytes
46 - 1500
bytes
4 bytes
Recepo
Eliminado
Enviado para a memria local
Transmisso
Adicionado
Buscado da memria local
Adicionado
FIGURA 2.3 Dados adicionados e removidos do quadro.
O prembulo constitudo de 62 bits 1 e 0 alternados, que tem a finalidade de

sincronizar transmissor e receptor. O delimitador de incio de quadro (SFD start of
frame delimiter) formado por dois bits 1, sinalizando que um novo quadro
iniciado. O CRC calculado durante a transmisso segundo o polinmio definido na
norma e adicionado ao final do quadro. Na recepo o CRC utilizado para a
verificao de integridade do quadro que chega da rede.
Esta interface mantm uma pequena memria local do tipo FIFO (First In First Out) de
16 bytes, que utilizada para a serializao dos dados a serem enviados ou recebidos da
rede. Este buffer busca ou envia os dados diretamente da memria local atravs do
barramento interno.
2.1.2 Microprocessador Interno

O microprocessador interno ao CI o responsvel pela execuo de toda a lgica
envolvida no processamento dos dados e sinais presentes no barramento interno, bem
como no barramento externo. Baseado nas suas rotinas, possvel executar com grande
24
facilidade e flexibilidade os processos envolvidos nos protocolos de rede e de driver de
dispositivo, neste caso especfico os padres IEEE 802.3 e NE 2000 respectivamente.
Esto disponveis ao usurio funes como reset, inicializao, envio de pacote pela
rede, configurao dos diversos formatos de dados e sinais, entre inmeras outras. O
processador responsvel tambm pela organizao dos dados recebidos e enviados
pela interface na memria local, baseado em alguns registradores de formatao
disponveis para este fim, proporcionando desta forma, a troca de dados de forma quase
transparente entre hospedeiro e rede.
2.1.3 Memria Local

A rea de memria interna ao CI onde os dados recebidos da rede so
temporariamente armazenados, com o fim de serem enviados ao hospedeiro, em um
segundo momento, a critrio dos processos de gerncia de dados que esto sendo
executados no computador local. possvel que em uma rede com muito trfego, esta
rea de memria estoure, quando ento procedimentos especiais devem ser tomados
pelo hospedeiro, com o fim de no comprometer o sistema de comunicao de dados
como um todo.
Esta mesma rea de memria compartilha o armazenamento dos dados enviados pelo
hospedeiro interface com o fim de serem colocados no cabo, e portanto alguns
cuidados devem ser tomados quanto definio de endereos dos dados que chegam e
os que saem, visando evitar a superposio de reas de dados. Outro recurso mantido na
memria o endereo fsico da interface de rede (endereo MAC) que utiliza uma
pequena rea desta, com o fim de armazenar em uma E2PROM (Electrically Erasable
Programmable Read Only Memory) o endereo de hardware e a largura do barramento
utilizado pelo hospedeiro, para o caso de um barramento ISA 8 ou 16 bits.
Na figura 2.4 podemos ver os detalhes de endereamento da memria local da interface
de rede.
0000h
D15
D8 D7
D0
PROM
001Fh
4000h
8k x 16bits
RAM Local
7FFFh
FFFFh
FIGURA 2.4 Memria local da interface de rede.
Na rea de endereos entre 0000h e 001Fh est localizada a E2PROM que mantm o
endereo MAC do dispositivo. interessante notar que este endereo est disponvel no
byte menos significativo (LSB) da palavra que forma o dado entre os endereos 0000h e
0005h (6 bytes). Tambm no byte LSB dos endereos entre 001Ch e 001Fh, estar
armazenado um cdigo numrico que indica o tamanho do barramento utilizado pela
interface para troca de dados com o hospedeiro. Este cdigo pode ser 42h, significando
25
largura de barramento de 8 bits, ou 57h, que significa barramento com 16 bits. Qualquer
outro cdigo no aceitvel pelo padro NE2000.
A rea de memria localizada entre os endereos 4000h e 7FFFh a que ser destinada
como buffer dos pacotes que chegam e saem da rede atravs da interface. O restante da
memria no utilizado conforme o padro estabelece.
2.1.4 Portas de E/S e Registradores

As portas de E/S e os registradores de configurao da interface de rede so diretamente
mapeados em endereos de E/S do barramento do hospedeiro, e abrangem uma rea de
endereamento de 32 posies. Na figura 2.5 pode-se notar a distribuio destes
registradores.
D15
D8
Base + 00h
Base + 0Fh
Base + 17h
D7
D0
Registradores
de
configurao
Portas de
transferncia de
dados
Base + 1Fh
Portas de
reset
FIGURA 2.5 Portas de E/S da interface de rede.
Os registradores de configurao da interface esto localizados entre os endereos Base

+ 00h e Base + 0Fh, possuindo todos 8 bits de largura, e so organizados em quatro
pginas, alternveis atravs do registrador de comando (CR) localizado na posio Base
+ 00h. O registrador de comando o nico sempre acessvel nas quatro pginas. As
tabelas 2.1 a 2.3 indicam a organizao das trs primeiras pginas de registradores, a
quarta pgina utilizada para testes, sendo normalmente desconsiderada.
TABELA 2.1 Registradores de configurao, pgina 0.

Endereo
00h
Leitura
CR Command
Escrita
CR - Command
01h
CLDA0 Current Local DMA Address 0
PSTART Page Start Register
02h
PSTOP Page Stop Register
03h
BNRY Boundary Pointer
BNRY Boundary Pointer
04h
TSR Transmit Status Register
TPSR Transmit Page Status Address
05h
NCR Number of Collisions Register
TBCR0 Transmit Byte Count Register 0
06h
FIFO
TBCR1 Transmit Byte Count Register 1
07h
ISR Interrupt Status Register
ISR Interrupt Status Register
08h
CRDA0 Current Remote DMA Adrress 0
RSAR0 Remote Start Address Register 0
09h
CRDA1 Current Remote DMA Adrress 1
0Ah
RSAR1 Remote Start Address Register 1

RBCR0 Remote Byte Count Register 0
0Bh
RBCR1 Remote Byte Count Register 1
0Ch
RSR Receive Status Register
RCR Receive Configuration Register
0Dh
CNTR0 Frame Alignmet Errors
TCR Transmit Configuration Register
0Eh
CNTR1 CRC Errors
DCR Data Configuration Register
0Fh
CNTR2 Missed Packets Errors
IMR Interrupt Mask Register
26
Endereo
Leitura
Escrita
00h
CR Command
CR - Command
01h
PAR0 Physical Address Register 0
02h
03h
04h
05h
06h
07h
CURR Current Page Register
CURR Current Page Register
08h
MAR0 Mutlicast Address Register 0
09h
0Ah
0Bh
0Ch
0Dh
0Eh
0Fh

Endereo
00h
Leitura
CR Command
Escrita
CR - Command
01h
PSTART Page Start Register
02h
PSTOP Page Stop Register
03h
04h
TPSR Transmit Page Status Address
05h
06h
07h
08h
09h
0Ah
0Bh
0Ch
RCR Receive Configuration Register
0Dh
TCR Transmit Configuration Register
0Eh
DCR Data Configuration Register
0Fh
IMR Interrupt Mask Register
Alm dos registradores de configurao, esto acessveis via o canal de E/S do

hospedeiro entre os endereos Base + 10h e Base + 17h oito portas que podem ser
utilizadas indistintamente para a transferncia de dados entre o hospedeiro e a memria
RAM local da interface de rede. A largura dos dados transferidos neste canal
dependente de configurao e da largura do barramento utilizado (dado disponvel na
E2PROM), podendo ser 8 ou 16 bits.
Na ltima faixa de endereos, entre Base + 18h e Base + 1Fh, possvel ativar o reset
interno da interface de rede. Para atingir tal fim, basta o hospedeiro realizar uma leitura
e a seguir uma escrita em qualquer dos endereos acima indicados.
27
Os registradores utilizados pela interface de rede tem funes distintas, como por
exemplo configurao, controle de DMA (direct memory access) interno, controle de
DMA externo, entre outras funes. Todos os registradores tem tamanho de 8 bits e so
acessados via endereos de E/S do hospedeiro.
2.1.4.1 CR Command Register
Utilizado para iniciar transmisses, habilitar o DMA remoto e na troca de pginas de
registradores. A tabela 2.4 demostra seu formato.
TABELA 2.4 Configurao do registrador CR.

Bit
Smbolo
Valor
D0
STP
01
D1
STA
10
D2
TXP
Descrio
Comando de reset de software
Comando de inicializao de software
Comando de envio de pacote pela rede (resetado aps envio)
D3
RD0
001
Comando de leitura remota (hospedeiro memria local)
D4
RD1
010
Comando de escrita remota (hospedeiro memria local)
D5
RD2
011
Envio automtico de pacotes (hospedeiro memria local)
1XX
Operao DMA completa ou abortada
D6
PS0
00
Seleciona pgina de registradores 0
D7
PS1
01
10
2.1.4.2 ISR Interrupt Status Register

Registrador acessado para determinar a causa de uma interrupo. Pode ser mascarvel
atravs do registrador IMR (Interrup Mask Register). Deve ser resetado, escrevendo 1
no bit correspondente, aps a ativao de uma interrupo, quando o bit cair a 0. A
tabela 2.5 demonstra quais interrupes so monitoradas por este registrador.
TABELA 2.5 Configurao do registrador ISR.

Bit
Smbolo
Valor
D0
PRX
Pacote recebido sem erros
Descrio
D1
PTX
Pacote transmitido sem erros
D2
RXE
Pacote recebido com erros (CRC, alinhamento, estouro no FIFO, pacote perdido)
D3
TXE
Pacote transmitido com erros (excesso de colises, FIFO vazia)
D4
OVW
Estouro da capacidade do anel de recepo (CURR atingiu BNRY)
D5
CNT
Estouro da capacidade (MSB = 1) de um dos contadores (CNTR0, CNTR1 ou CNTR2)
D6
RDC
Operao de DMA remota completa
D7
RST
Interface entrou em estado de reset por comando ou quando o anel de recepo estoura
2.1.4.3 IMR Interrupt Mask Register

Registrador utilizado para mascarar interrupes. Deve ser escrito 1 para habilitar a
interrupo correspondente, e 0 para desabilitar. Este registrador inicializado com
28
todas as interrupes desabilitadas. Na tabela 2.6 podemos ver as configuraes deste
registrador.
TABELA 2.6 Configurao do registrador IMR.

Bit
Smbolo
Valor
D0
PRXE
Descrio
Habilita interrupo de pacote recebido sem erros
D1
PTXE
Habilita interrupo de pacote transmitido sem erros
D2
RXEE
Habilita interrupo de pacote recebido com erros
D3
TXEE
Habilita interrupo de pacote transmitido com erros
D4
OVWE
Habilita interrupo de estouro da capacidade do anel de recepo
D5
CNTE
Habilita interrupo de estouro da capacidade de um dos contadores
D6
RDCE
Habilita interrupo de operao de DMA remota completa
2.1.4.4 DCR Data Configuration Register

Registrador que configura o formato de dados utilizado pela interface, conforme
observado na tabela 2.7.
TABELA 2.7 Configurao do registrador DCR.

Bit
Smbolo
Valor
D0
WTS
0
1
Tamanho de palavra utilizado no DMA local e remoto igual a 16 bits
D1
BOS
MSB em D15 D8, LSB em D7 D0 (80x86)
MSB em D7 D0, LSB em D15 D8 (680x0)
D2
LAS
DMA dual (modo de 16 bits)
DMA simples (modo de 32 bits)
D3
LS
Modo de loop selecionado (em conjunto com D1 e D2 do TCR)
Modo de operao normal.
D4
ARM
Descrio
Tamanho de palavra utilizado no DMA local e remoto igual a 8 bits
Comando de envio automtico de pacotes desabilitado
Comando de envio automtico de pacotes habilitado
D5
FT0
00
D6
FT1
01
Nmero de bytes presentes no FIFO para buscar/enviar dados da mem. local (2 bytes)
10
11
2.1.4.5 TCR Transmit Configuration Register

Configura a interface no que tange a transmisso de dados na rede. A tabela 2.8 ilustra
as configuraes deste registrador.
29
TABELA 2.8 Configurao do registrador TCR.
Bit
Smbolo
Valor
D0
CRC
Descrio
D1
LB0
00
Operao normal
D2
LB1
01
Loop interno da interface (tipo 1)
10
Loop interno da interface (tipo 2)
Habilitada a gerao de CRC e adio no pacote transmitido
11
Loop externo
D3
ATD
Permite a inibio remota da interface atravs da recepo de um pacote especial
D4
OFST
Fora a mudana do algoritmo normal de backoff utilizado durante colises
2.1.4.6 TSR Transmit Status Register

Registrador que mantm o status de uma transmisso. limpo no incio de cada nova
transmisso e deve ser lido ao seu trmino. Na tabela 2.9 podemos observar os possveis
eventos de transmisso.
TABELA 2.9 Configurao do registrador TSR.

Bit
Smbolo
Valor
D0
PTX
Descrio
Pacote transmitido com sucesso
D1
D2
COL
Pelo menos uma coliso ocorreu durante a transmisso
D3
ABT
Transmisso cancelada por colises excessivas (16 colises)
D4
CRS
Portadora perdida durante a transmisso (transmisso no ser cancelada)
D5
FU
Transmisso cancelada por falta de dados no FIFO
D6
CDH
Falha na transmisso do sinal de coliso aps a transmisso de um pacote
D7
OWC
Coliso ocorreu aps o slot time (51,2s)
2.1.4.7 RSR Receive Configuration Register

Configura a interface no que tange a recepo de dados da rede. A tabela 2.10 ilustra as
configuraes deste registrador.
TABELA 2.10 Configurao do registrador TCR.

Bit
Smbolo
Valor
D0
SEP
Pacotes com erro de CRC e alinhamento so aceitos
Descrio
D1
AR
Pacotes com menos que 64 bytes so aceitos
D2
AB
Pacotes com endereo de destino broadcast so aceitos
D3
AM
Pacotes com endereo de destino multicast so aceitos
D4
PRO
Habilita o modo promscuo
D5
MON
Recebe os pacotes destinados interface e com CRC correto, mas no os envia memria (CNTR2
incrementado)
30
2.1.4.8 RSR Receive Status Register
Registrador que mantm o status de uma recepo. limpo no incio de cada nova
recepo e ao seu trmino enviado juntamente com o pacote memria local. Na
tabela 2.11 podemos observar os possveis eventos de recepo.
TABELA 2.11 Configurao do registrador TSR.

Bit
Smbolo
Valor
D0
PRX
Descrio
D1
CRC
00
Pacote recebido sem erros
D2
FAE
01
Pacote recebido com erro de CRC (CNTR1 incrementado)
11
Pacote recebido com erro de alinhamento e CRC (CNTR0 incrementado)
D3
FO
Recepo cancelada por falta de extrao de dados do FIFO
D4
MPA
Pacote recebido, mas por algum motivo no pode ser enviado memria local (CNTR2
incrementado)
D5
PHY
Pacote recebido por endereo fsico
Pacote recebido por endereo de multicast
Pacote recebido com sucesso
D6
DIS
Receptor em modo monitor
D7
DFR
Sinais de deteco de portadora e de coliso gerados pela interface
2.1.4.9 Registradores de Controle do DMA Local para Transmisso

O registrador TPSR aponta para o ponto inicial do pacote na memria local, que deve
ser transmitido pela interface na rede. utilizado apenas o byte mais significativo
(MSB) porque a memria local segmentada em blocos de 256 bytes. O par de
registradores TBCR0 e TBCR1 receber o tamanho do pacote, que pode chegar a 64
kbytes, ficando por conta do programador a organizao dos pacotes com sua rea de
dados entre 64 e 1500 bytes de tamanho, bem como a sua estruturao, segundo o
formato de pacote Ethernet.
Aps a inicializar dos registradores de transmisso, o bit TXP do registrador de
comando (CR) pode ser setado acarretando na carga da FIFO com os dados da memria
local, de forma seqencial, com o fim de serem injetados no cabo.
2.1.4.10
Registradores de Controle do DMA Local para Recepo
A memria local organizada em segmentos de 256 bytes com a forma de um anel,

portanto mecanismos devem ser previstos para evitar a superposio de dados ainda no
requisitados pelo hospedeiro com dados que chegam pela rede. Para atingir este fim
quatro registradores esto disponveis para o usurio: PSTART que delimita a posio
de memria local inicial utilizada pelo anel; PSTOP que delimita o fim do anel; CURR
que aponta para aposio ao longo do anel na qual deve ser escrito o prximo pacote
que chega da rede; e, BNRY que aponta para o prximo pacote que deve ser retirado do
anel pelo hospedeiro utilizando o canal de DMA remoto.
Ao receber um pacote a interface verifica a posio atual de escrita (CURR) e a
compara com PSTOP. Caso seja igual, ento foi atingida a posio mxima permitida
ao anel e CURR ser igualado a PSTART, ou seja, localizado no incio da rea de
memria novamente. Aps comparado CURR com o contedo de BNRY, que se
31
forem iguais indicar que acontecer sobrescrita em dados ainda no requisitados pelo
hospedeiro. Neste caso a recepo suspensa e uma interrupo gerada, com o fim de
avisar o hospedeiro que os dados devem ser retirados do anel, utilizado-se para isto um
processo de reinicializao da interface definido pelo fabricante.
2.1.4.11
Registradores de Controle de DMA Remoto
O DMA remoto utilizado com o fim de extrair dados da memria interna da interface
de rede, e envi-los memria do hospedeiro e vice-versa. Os registradores de controle
desta transferncia so RSAR0 e RSAR1 que apontam para a rea da memria local
onde deve se iniciar a transferncia e, RBCR0 e RBCR1 que contm o tamanho da rea
de dados a ser transmitida.
Aps preencher convenientemente o valor destes registradores, poder ser emitido um
comando de leitura remota, de escrita remota ou de envio de pacote, utilizando-se para
tanto os bits RD0, RD1 e RD2 do registrador de comando (CR).
Quando for emitido um comando de leitura remota cada posio de memria local ser
escrita na porta de E/S da interface aguardando ser lida pelo hospedeiro via um
comando de leitura de E/S do processador. A partir do ponto inicial indicado por RSAR,
a leitura continuar seqencialmente at atingir a quantidade mxima de dados indicada
por RBCR. O comando de escrita remota tem um procedimento semelhante, mas com a
direo do fluxo de dados inversa, ou seja, o hospedeiro escreve os dados a serem
enviados para a memria local na porta de E/S, e estes dados so encaminhados, via o
canal de DMA remoto, para a memria local.
O comando de envio de pacote possibilita a automao do processo de transferncia de
dados entre a memria local e o hospedeiro, movimentando adequadamente os ponteiros
RSAR, RBCR e BNRY com o fim de enviar o prximo pacote que se encontra na
memria local para o hospedeiro, liberando o programador da codificao de rotinas de
gerncia deste tipo de transferncia. Aps o ajuste deste bit do registrador de comando
(CR), o processador interno da interface de rede executa todos os procedimentos
necessrios visando a transferncia de um pacote completo da memria local para a
memria do hospedeiro. Fica a cargo do programador a codificao de uma rotina de
leitura da porta de E/S da interface, com o fim de colocar os dados disponibilizados, de
forma seqencial, na memria do hospedeiro.
2.2 O Cdigo Pingador

A primeira aproximao com a pilha de protocolos TCP/IP foi executada utilizando a
seqncia de testes prevista no utilitrio PING (Packet Internet Groper). Para tanto, foi
implementado com a utilizao da linguagem C [KER 86], [SCH 97], o cdigo que
responde a uma solicitao de eco. Desta forma, o sistema reproduz o elo secundrio
previsto no teste de funcionalidade da pilha TCP/IP.
A implementao foi executada utilizando um PC com processador 80386 e 16 MB de
memria RAM. Uma placa de rede que emula o padro NE2000 foi pea fundamental,
uma vez que desta forma tornou-se vivel o acesso direto ao hardware de rede,
32
utilizando o padro, evitando desta forma, o uso de drivers complexos ou outros
artifcios junto ao sistema operacional do microcomputador (DOS 6.22).
A linguagem C foi escolhida devido sua facilidade de acesso direto ao hardware,
utilizado no dispositivo de conexo de rede (Controlador Ethernet). Com o conjunto PC,
DOS e C, o ambiente de desenvolvimento tornou-se bastante flexvel e relativamente
fcil de programar. Esta facilidade de acesso ao hardware no estaria disponvel,
durante a fase de desenvolvimento, caso se optasse pelo uso da linguagem Java, o que
fatalmente levaria utilizao de drivers de dispositivo, transformando-se em um
empecilho a mais no cdigo resultante.
Como diretriz bsica do trabalho ficou estabelecido que o cdigo, bem como os recursos
de hardware utilizados, deveriam ser os mais simples possvel, evitando portanto,
sofisticaes desnecessrias ao correto funcionamento do protocolo. Esta simplificao
baseada no fato de que o cdigo resultante, devidamente traduzido para Java, servir
como fonte de entrada para a ferramenta SASHIMI, que por sua vez produzir o cdigo
necessrio para a sintetizao em hardware do processador de aplicao especfica
TCP/IP. Tendo em vista as limitaes que o hardware impe quanto rea de silcio
ocupada pelo cdigo produzido pela ferramenta utilizada, ficou estabelecido que quanto
menos recursos fossem utilizados na fase de desenvolvimento, mais simples e exeqvel
seria a integrao em hardware dos resultados finais. Para tanto, nesta primeira
implementao um pequeno subconjunto do universo de possibilidades dos protocolos
da pilha envolvidos no processo de PING foram utilizados.
A prpria linguagem de programao foi utilizada tendo em mente a simplicidade do
cdigo resultante, procurando-se, na medida do possvel, evitar o uso de construes
complexas. Funes de muitas bibliotecas disponveis no C foram evitadas, bem como a
utilizao de operadores mais sofisticados, como por exemplo, a multiplicao, a
diviso, entre outros.
2.2.1 O Utilitrio PING

Visando a depurao e localizao de defeitos na rede TCP/IP [COM 98], foi
padronizada uma ferramenta de depurao baseada na solicitao de eco (echo request)
e a resposta ao eco (echo reply). Um hospedeiro envia uma solicitao de eco, e o
hospedeiro destino deve responder a esta solicitao retornado origem um pacote com
determinada formatao.
A mensagem que flui pela rede como resultado de uma requisio possui uma rea de
dados opcional, que caso exista no pacote gerado na origem, deve retornar exatamente
igual no pacote de resposta.
Para o correto encaminhamento da solicitao PING todos os protocolos inferiores ao
aplicativo devem estar habilitados e funcionais, sendo portanto um teste efetivo quanto
funcionalidade, no s dos hospedeiros origem e destino, mas tambm de toda a
interligao de redes que eventualmente exista entre eles.
O utilitrio PING se utiliza do protocolo ICMP (Internet Control Message Protocol)
[POS 81a] para executar o teste de funcionalidade em rede. O ICMP prev uma
solicitao de eco e uma resposta a esta solicitao, utilizando um pacote como o
mostrado na figura 2.6.
33
Tamanho em bytes
Tipo
Cdigo
Soma de verificao
Identificador
Nmero de seqncia
Dados opcionais
FIGURA 2.6 - Formato da mensagem de eco (ICMP).
O campo Tipo possui o valor 8 para a solicitao de eco, ou o valor 0 para a resposta. O
campo Cdigo sempre tem o valor 0, a Soma de verificao gerada na origem do
pacote e utilizada pelo destino para a verificao de erros de transmisso. Os campos
Identificador e Nmero de seqncia so utilizados pelo hospedeiro que solicita o eco
com o fim de combinar suas solicitaes com as respostas adequadas.
Alm do protocolo ICMP o PING verifica a funcionalidade do protocolo IP (Internet
Protocol) [POS 81], sobre o qual o ICMP transportado, e no caso do nvel fsico ser o
Ethernet, ento o protocolo ARP (Address Resolution Protocol) [PLU 82] dever estar
operacional tambm.
2.2.2 O Hardware de Rede

A implementao foi baseada no padro NE2000, que possibilita o acesso ao hardware
de rede diretamente pelo software elaborado em C durante a fase de desenvolvimento,
dispensando a utilizao de drivers de dispositivo de qualquer espcie. Vrios
fabricantes de Circuitos Integrados (CI) produzem controladores de rede que
implementam o padro na interface entre o software e os registradores de nvel fsico,
disponibilizando seus manuais, com toda a informao necessria ao correto acesso de
seus controladores.
Para o bom funcionamento do hardware de rede, alguns registradores devem ser
inicializados com valores especficos, dependendo da forma de acesso que o hospedeiro
utilizar no tocante transferncia de dados da rede e a forma de acesso memria
interna (memria local) do controlador. O modo de operao padro do NE2000 o
formato de acesso aos dados via E/S, sendo este o formato padro de alguns
controladores comerciais que seguem o padro. Neste formato toda a troca de dados
entre a memria do hospedeiro e a memria local do controlador Ethernet, ser baseada
em comandos de leitura ou escrita em E/S do processador utilizado no hospedeiro.
A partir deste ponto a programao dos diversos registradores do controlador seguem as
especificaes NE2000 para o correto funcionamento da troca de dados entre
hospedeiro e rede. A rotina de preparao do hardware de rede utilizado no cdigo
envia valores adequados aos registradores da placa de rede visando coloc-la
operacional na rede local Ethernet.
Outro aspecto importante da rotina de inicializao a preparao do hardware de
tratamento de interrupes do microcomputador, visando iniciar o tratamento das
interrupes geradas pela placa de rede. Com esta inteno ajustado o vetor de
interrupes do sistema operacional com o endereo da nova rotina de tratamento de
34
interrupes (ISR Interrupt Service Routine), que substituir a funcionalidade original
da rotina de tratamento de interrupes do sistema operacional, por uma nova
funcionalidade, de acordo com as necessidades do controlador de rede utilizado.
Esta ISR prev o tratamento de trs eventos bsicos, conforme demostra o fluxograma
apresentado na figura 2.7:
A recepo de um pacote da rede sem erros;
A transmisso para a rede de um pacote sem erros;
A ocorrncia de um erro de transmisso.
Incio ISR
ISR = Interrupt Status Register

PTX = Pacote Transmitido
PRX = Pacote recebido
OVW = Overflow do anel
TXE = Erro na transmisso
RDC = DMA remoto completo
CURR = Ponteiro de escrita no anel
BNRY = Ponteiro de leitura do anel
Desabilita interrupes
Desabilita IRQ 5
ISR = PRX
?
ISR = OVW
?
Ativa modo loop
N
Reseta OVW
BufTx0 =
TX ?
Reseta PTX
BufTx1 =
Aguarda?
S
Envia BufTx1
BuscaPct ( )
ISR = PTX
?
N
BufTx0 =
Aguarda?
ExistePct ( )
?
N
Desativa modo loop
S
Envia BufTx0
ISR = TXE
?
Habilita IRQ 5
S
Reseta TXE
BufTx0 =
Tx
BufTx0 = Vazio
N
BufTx0 = Vazio
FIGURA 2.7 Fluxo da rotina de tratamento de interrupes.
Fim
35
2.2.3 Recepo de Dados da Rede

O evento de recepo de um ou mais pacotes da rede tratado atravs da retirada dos
dados da memria local do controlador de rede, onde os pacotes so automaticamente
colocados durante sua recepo, e aguardam serem retirados pelo hospedeiro atravs de
operaes de E/S do processador. Eventualmente, pode ocorrer que a memria interna
estoure devido chegada de uma quantidade maior de dados da rede que o hospedeiro
pode retirar da memria interna. Neste caso, uma interrupo gerada pelo controlador,
e como conseqncia, este colocado em modo de lao, evitando o recebimento de
mais dados. Com este artifcio gerada a condio para que o hospedeiro esvazie a
memria local. A seguir o processo de recepo de dados reinicializado, evitando
desta forma, a sobrescrita dos dados j recebidos da rede.
As funes diretamente envolvidas neste processo so BuscaPct() e
ExistePct(). A primeira funo executa as operaes necessrias de E/S visando
retirar da memria local do controlador de rede o pacote recm chegado, e transferi-lo
memria principal do microcomputador. Aps este processo, feita uma anlise do
contedo do pacote visando determinar se seu destino a mquina local. Aps, feito o
encaminhamento rotina de tratamento de protocolo adequada. No caso do software
pingador, apenas duas possibilidades de protocolo esto disponveis: ARP e ICMP. A
figura 2.8 ilustra o processo da rotina BuscaPct().
BuscaPct ( )
Reseta PRX
Busca Dado da Placa
ISR = RDC
?
S
Reseta RDC
Solicitao
ARP ?
ArpResp ( )
Solicitao
echo ICMP ?
IcmpResp ( )
Fim
FIGURA 2.8 Fluxo da rotina BuscaPct().
A funo ExistePct() executa o procedimento de verificao se a memria local do

controlador de rede est vazia. utilizada durante o processo de retirada de dados da
memria local evitando, desta forma, que pacotes sejam deixados no controlador,
36
ocupando espao de memria, e deixando de ser tratados pelo protocolo. A figura 2.9
ilustra seu processo interno.
ExistePct ( )
CURR =
BNRY ?
S
Retorna No
Retorna Sim
Fim
FIGURA 2.9 Fluxo da rotina ExistePct().
2.2.4 Envio de Dados para a Rede

A funo responsvel pela transmisso de dados para a rede a EnviaPct(). Na
memria local do controlador de rede existem duas reas onde devem ser colocados os
pacotes que sero enviados. Aps a carga dos dados na memria local do controlador de
rede, atravs de operaes de E/S, este ajustado para o envio destes dados atravs da
rede.
As duas reas de memria para a transmisso podem ser utilizadas de forma
entrelaada, de maneira que enquanto uma est transmitindo seus dados atravs do
controlador, a outra pode ser carregada com novos dados vindos do hospedeiro. Desta
forma pode ser obtido um substancial aumento na performance de transmisso de dados.
O processo desta funo est ilustrado na figura 2.10.
37
EnviaPct ( Tam )
BufTx0 =
Vazio ?
S
Envia Dado a Placa
(BufTx0)
Envia Dado a Placa

(BufTx1)
ISR = RDC
?
S
ISR = RDC
?
S
Reseta RDC
Reseta RDC
BufTx0 = Aguarda
BufTx1 = Aguarda
Transmitindo
Pacote?
Envia Pacote
S
Fim
FIGURA 2.10 Fluxo da rotina EnviaPct().
O primeiro passo verificar qual a rea de memria est vazia para o envio de um novo
pacote. Aps, a operao de E/S executada transferindo os dados da memria do
hospedeiro para a memria local do controlador. A seguir, se possvel, o controlador de
rede imediatamente ajustado para o envio do pacote pela rede. Caso o envio imediato
no seja vivel, porque o canal de transmisso de dados via rede est ocupado, ento a
rotina de tratamento de interrupes se responsabilizar pelo seu envio no devido
tempo.
2.2.5 O Protocolo
A implementao do software pingador bastante simplificada no que tange os recursos
dos protocolos aplicados, sendo desenvolvido apenas o necessrio para o correto
funcionamento com as caractersticas que o utilitrio PING deseja encontrar.
Sob este ponto de vista apenas trs funes se tornaram necessrias, a saber:
A funo de prova da soma de verificao dos cabealhos, CheckSum();
A funo de elaborao da resposta a uma solicitao de resoluo de endereo

fsico (ARP), ArpResp();
A funo de elaborao da resposta a uma solicitao de eco (ICMP),

IcmpResp().
38
2.2.6 Soma de Verificao

Segundo o protocolo IP, o cabealho de cada pacote possui um campo de verificao da
integridade fsica dos dados ali disponveis. Com este artifcio pode ser detectado um
pacote com dados corrompidos na rea de cabealho, o que fatalmente acarretar no seu
descarte. Embora o nvel de enlace de dados adotado (Ethernet) providencie uma forma
de verificao de integridade do pacote como um todo, atravs de clculo de CRC
(Cyclic Redundant Check), que por si s altamente eficiente na deteco de erros de
transmisso, o IP prev mais este nvel de segurana quanto aos dados que chegam. O
controlador de rede fornece de forma automtica a verificao dos pacotes Ethernet que
chegam, bem como o clculo do CRC para os pacotes que saem.
O tipo de teste de verificao adotado, para o caso do IP, a soma em complemento de
um, aplicada somente sobre a rea de dados do cabealho IP nos pacotes que chegam. O
procedimento adotado a partir da deteco de um pacote defeituoso o seu descarte. O
mesmo processo adotado, mas de forma inversa, sobre os pacotes que saem. Neste
caso a soma de verificao calculada e adicionada ao cabealho IP no campo
adequado.
2.2.7 A Resposta ARP

Na rede local, a nica forma de localizar um determinado hospedeiro atravs do
protocolo de resoluo de endereo IP [POS 81] em endereo fsico, viabilizando assim
a remessa de um pacote de dados no nvel de enlace de dados de um hospedeiro a outro.
Para maiores detalhes do protocolo ver o desenvolvimento ARP especfico, na seo
2.5. Com este fim foi especificado o protocolo ARP [PLU 82], que se tornou parte
integrante da pilha TCP/IP nas redes locais que seguem a especificao Ethernet.
Este protocolo foi implementado no software pingador, visando sua correta
funcionalidade na rede local. A funo RespArp() recebe o pacote com uma
solicitao de resoluo de endereo remetido para a mquina local, e constri uma
resposta adequada. A seguir envia esta resposta funo de envio de pacotes para a
rede, com o fim de que a resposta chegue ao hospedeiro originador da requisio.
De posse do dado necessrio (endereo fsico) para o envio de um pacote Ethernet, o
hospedeiro de origem pode ento executar a entrega do pacote de solicitao de eco, que
em ltima anlise o objetivo do software implementado. O ARP implementado possui
apenas uma frao da funcionalidade prevista no padro, visando exclusivamente a
economia de recursos de hardware e software.
2.2.8 A resposta ICMP

Ao receber um pacote IP com uma solicitao de eco, a funo BuscaPct() verifica
se o destino o endereo IP local, se a soma de verificao do cabealho IP est correta,
se a verso do protocolo IP a verso corrente e, por fim, se a soma de verificao do
cabealho ICMP est certa. A soma de verificao do cabealho ICMP segue as mesmas
regras do cabealho IP quanto abrangncia e formato.
Aps esta verificao o pacote enviado para a funo de elaborao de resposta de
eco, que montar a resposta conforme o protocolo ICMP prev. Basicamente os
39
endereos de origem e destino so invertidos no pacote e as somas de verificao dos
cabealhos IP e ICMP so recalculadas. A seguir a funo de envio de pacotes
chamada, injetando a resposta elaborada localmente na rede, e o processo finaliza.
2.3 Funes Auxiliares

Durante o progresso da implementao do software de emulao do protocolo TCP/IP
no PC, foi surgindo a necessidade de codificao de algumas funes acessrias, mas de
fundamental importncia para o correto desempenho do sistema como um todo. Tais
funes sero objeto de anlise desta seo, visando a compreenso correta da forma de
implementao do sistema.
As funes elaboradas so as a seguir relacionadas:
Funo de clculo de soma de verificao
Funo de inverso de bytes de uma word
Funo de temporizao
Funo de soma de 32 bits
Estas funes tornaram-se necessrias em sua maioria devido s limitaes impostas

pelo sistema operacional utilizado (DOS 6.22). Por outro lado a futura implementao
em hardware (VHDL) do cdigo proposto pode ser vantajosa sob o aspecto de que no
so utilizadas rotinas proprietrias do sistema operacional utilizado para o
desenvolvimento, as quais no estariam presentes na implementao do hardware final.
2.3.1 O Clculo de Soma de Verificao

A forma de clculo de soma de verificao utilizada pelos protocolos IP (Internet
Protocol), ICMP (Internet Control Message Protocol) e TCP (Transmission Control
Protocol) [COM 98] [COM99] a mesma segundo as respectivas RFCs (Request For
Comment) que os padronizam [POS 81] [POS 81a] [POS 81b]. Portanto, surgiu de
imediato a necessidade de desenvolvimento de uma funo acessvel aos trs protocolos
que gerasse tal soma de verificao.
O formato desta verificao baseado em palavras de 16 bits que so separadas em seus
bytes menos significativos (LSB) e nos mais significativos (MSB). A seguir so
somados todos os LSBs da rea de dados que se deseja fazer a verificao. De forma
semelhante os MSBs tambm so somados entre si.
Ao final desta operao restam dois nmeros que representam a soma dos bytes LSB e a
soma dos bytes MSB, mas estes nmeros devem possuir uma largura de 8 bits, portanto
a seguir o dgito de vai um, que eventualmente tenha surgido na soma LSB, deve ser
acrescido ao MSB. De forma semelhante o vai um do MSB deve ser acrescido ao
LSB, restando no fim dos clculos duas quantidades do tamanho de um byte cada.
40
A seguir as duas quantidades devem ser agrupadas novamente, voltando a possuir 16
bits de largura, e a quantidade final deve ser invertida bit a bit, resultando finalmente na
soma de verificao da rea de dados enviada para a funo de clculo.
A soma de verificao possui uma caracterstica interessante para o protocolo que a de
verificao de integridade dos dados recebidos da rede. Baseado nesta caracterstica, ao
ser executada tal verificao sobre os dados o resultado da operao dever ser zero,
desde que se inclua na rea de dados a soma de verificao que foi recebida juntamente
com o pacote de dados. A figura 2.11 ilustra o fluxo desta rotina.
CheckSum( )
Soma LSB
Soma MSB
Fim da rea
de Dados?
S
Soma vai um do LSB ao

MSB
Soma vai um do MSB ao

LSB
Reagrupa MSB ao LSB e

complementa bit a bit
Fim
FIGURA 2.11 Fluxo da rotina de clculo de soma de verificao.
2.3.2 Funo de Inverso MSB LSB

A ordem de armazenamento dos bytes presentes na memria do PC conhecida como
Little Endian, isto , na posio de memria com endereo de menor valor armazena o
byte de maior valor de uma palavra, e na posio de memria de maior valor encontrase o byte de menor valor. Por conveno os dados que fluem na rede, que utilizam a
pilha TCP/IP, seguem o formato conhecido como Big Endian, exatamente o oposto
encontrado no PC.
Por conseqncia, sempre que for necessria a troca de dados de 16 bits entre o
hospedeiro e a rede, uma converso de formato dever ser utilizada, invertendo o byte
MSB com o LSB. Desta forma teremos no hospedeiro o formato LSB MSB, ao passo
que na rede o formato ser MSB LSB.
Para resolver este problema, uma pequena funo de converso foi implementada,
chamada de Inverte(), que tem o objetivo de retornar a palavra que recebeu como
argumento, invertida nos seus bytes MSB e LSB.
41
Com a utilizao deste artifcio fica simples o processo de, por exemplo, realizar a soma
de dois nmeros inteiros de 16 bits de largura, recebidos da rede pelo processador do
PC, e a seguir retornar o resultado de 16 bits novamente para a rede. importante notar
que esta preocupao no atinge valores codificados em 8 bits, onde neste caso a
aritmtica com dados vindos da rede direta.
2.3.3 Funo de Temporizao

Temporizao um requisito fundamental no protocolo TCP/IP, uma vez que vrios
aspectos se baseiam no tempo decorrido entre dois eventos. Por exemplo, em diversas
situaes pode-se deparar com tempo de vida de uma determinada informao. Mais
especificamente, os dados contidos na tabela ARP possuem uma determinada vida til,
aps a qual devem ser descartados. O protocolo TCP utiliza muito temporizadores com
o fim de determinar tempos de espera por alguma informao que esteja para chegar
pela rede.
Com o fim de prover uma fonte de tempo ao programa desenvolvido, e no depender do
sistema operacional para isto, foi implementado um temporizador que cadencia todo o
sistema, sendo utilizado apenas o temporizador do computador hospedeiro como fonte
da constante de tempo. Mais tarde, quando da implementao em hardware, um
temporizador simples poder facilmente ser utilizado em substituio ao do computador
hospedeiro sem grandes alteraes na lgica proposta.
O temporizador do PC fornece a constante de tempo com uma cadncia de 18,21Hz, ou
mais precisamente, uma interrupo do processador (IRQ 0) a cada 54,9ms [SHA 95],
[PRE 99]. O vetor de interrupes foi ajustado para que, juntamente com as funes
normais do sistema operacional quando da ocorrncia da interrupo 0, fosse
processado um pequeno fragmento de cdigo pela ISR (Interrupt Service Routine).
O cdigo executado inicialmente desabilita todas as interrupes, e a seguir incrementa
algumas variveis do programa que tero seus valores ajustados de acordo com o tempo
decorrido. Uma varivel para a constante de tempo do timer do PC, atualizada a cada
54,9ms, uma varivel para os segundos, uma para os minutos e uma para as horas.
Aps atualizar convenientemente as variveis contadoras de tempo, as interrupes do
PC so restauradas e o controlador de interrupes do PC (PIC Programmable
Interrupt Controller) avisado do fim do tratamento desta interrupo.
A partir da atualizao constante destas variveis de tempo, os diversos protocolos e
funes que necessitem de medio de tempo decorrido, podem manter variveis
auxiliares, e atravs de comparao, incremento ou decremento, baseados nas variveis
principais de contagem de tempo, tero uma preciso razovel na noo de tempo
transcorrido entre dois eventos quaisquer.
A lgica da funo de atualizao das variveis temporizadoras intencionalmente
simples e curta, tendo em vista que esta funo ser executada aproximadamente 18
vezes por segundo, e todas as interrupes do PC estaro inibidas durante sua execuo.
A figura 2.12 a seguir d uma idia da forma de implementao da funo de
temporizao.
42
ISRTimer( )
Desabilita interrupes
Incrementa CTempo
CTempo
= 18?
S
Zera CTempo
Incrementa Seg
Seg = 60
?
S
Zera Seg
Incrementa Min
Min = 60
?
S
Zera Min
Incrementa Hora
Fim de tratamento PIC

Habilita interrupes
Fim
FIGURA 2.12 Fluxo da rotina de temporizao.
2.3.4 Funo de Soma de 32 Bits

O sistema operacional utilizado para a implementao do sistema TCP/IP foi o DOS
6.22, que um sistema operacional de 16 bits. Este sistema operacional no executa
funes que envolvam inteiros de 32 bits de tamanho.
Algumas operaes previstas no protocolo TCP utilizam dados de 32 bits, e para
executar as rotinas pertinentes adequadamente, uma funo de soma de 32 bits foi
codificada e recebeu o nome de Soma(). Esta funo recebe como argumento as
palavras mais significativa e menos significativa do inteiro de 32 bits correspondente ao
primeiro operando da soma. Recebe tambm um valor de tamanho de 16 bits que ser o
segundo operando da operao. A seguir o segundo operando adicionado palavra
menos significativa da palavra de 32 bits (primeiro operando), e verificado se a
operao produziu o bit de vai um. No caso afirmativo, ento a palavra mais
significativa do primeiro operando deve ser adicionada de um, caso negativo, nada deve
ser feito, e o resultado da soma estar pronto.
43
Os campos do cabealho TCP que utilizam inteiros de 32 bits so os dos nmeros de
seqncia e de reconhecimento, que para o caso aqui apresentado, nunca recebero ou
enviaro um segmento TCP com mais que 1460 bytes de dados. Isto ocorre devido
rea de dados mxima do quadro Ethernet ser de 1500 bytes, da subtraindo-se o
cabealho IP (20 bytes) e o cabealho TCP (20 bytes) obtm-se 1460 bytes. Adicione-se
a isto que os quadros de aplicao transmitidos neste trabalho so bastante sucintos, e
nunca atingiro os 1460 bytes disponveis .Por este motivo a funo de soma de 32 bits
que ser utilizada para gerar os nmeros de reconhecimento e de seqncia TCP, tem
como segundo operando um inteiro de 16 bits. Isto ocorre porque no so necessrios
mais que 11 bits para representar 1460, o maior nmero que poder ser acrescido a estes
campos.
Os protocolos utilizados na pilha TCP/IP, implementados neste trabalho, sero objeto de
anlise das sees seguintes, apresentando suas aproximaes e simplificaes visando
atingir o menor tamanho de cdigo possvel.
2.4 O Padro Ethernet

O padro Ethernet possivelmente o protocolo de nvel dois mais difundido e utilizado,
sendo normalizado pelo IEEE sob o nmero 802.3 [IEE 96]. Possui o endereo de
hardware de seis bytes codificado diretamente sobre a interface de rede, com numerao
exclusiva e nunca repetida. O formato do quadro Ethernet apresentado na figura 2.13.
Tamanho em Bytes
Prembulo
Delimitador de Incio de Quadro
Endereo de Destino
Endereo de Origem
Tipo de Dados
Dados ou Enchimento
Min. 46 e mx. 1500 bytes
CRC
FIGURA 2.13 - Cabealho do quadro Ethernet
O Prembulo constitudo de sete bytes com o padro 10101010 com o objetivo de

sincronizar o receptor e o Delimitador de Incio de Quadro possui o padro 10101011.
O Endereo de Destino vem antes do Endereo de Origem, com a finalidade de um
rpido entendimento por parte do hardware receptor, se o quadro se destina a ele e,
portanto, deve ser completamente recebido e processado, ou deve ser imediatamente
ignorado. Os dois bytes seguintes definem o tipo de protocolo que est encapsulado no
quadro, com a finalidade de um correto encaminhamento para a rotina de software
pertinente, abrindo desta forma a possibilidade de que numa mesma rede trafeguem
protocolos completamente diferentes sem possibilidade de interferncia mtua.
A seguir encontram-se os dados que o quadro carrega, devendo ser observado os limites
mximo (MTU) e mnimo de um quadro Ethernet. Caso os dados encapsulados possuam
menos que 46 bytes, ento um enchimento deve ser utilizado para atingir o mnimo
exigido. A seguir existem 4 bytes do cdigo de verificao de erros que do tipo CRC.
44
2.4.1 Ethernet no CI Controlador de Rede

O Circuito Integrado controlador de rede utilizado encapsula em hardware praticamente
todas as funes relativas ao nvel fsico e de enlace de dados, tornado desta forma o
processo de envio e recepo de um pacote pela rede bastante simplificado.
Tais funes so completamente transparentes ao usurio, mas devem ser lembradas
principalmente devido sua complexidade. Caso devessem ser desenvolvidas pelo
projetista que implementar o uso do controlador de rede, certamente aumentariam em
muito a complexidade do cdigo resultante, de forma a talvez inviabilizar o projeto,
principalmente em se considerando os escassos recursos de memria e processamento,
normalmente presentes nas implementaes mais econmicas.
As funes integradas no CI controlador so descritas sucintamente a seguir:
Adaptao do sinal de entrada: consiste de vrios filtros e circuitos

reconhecedores do sinal tpico presente no cabo de rede. Estes adaptadores garantem
que sinais resultantes de interferncias no sobrecarreguem os circuitos seguintes.
Detetor de colises: Reconhece e trata as colises ocorridas no cabo de rede, tanto

do ponto de vista fsico, ou seja, o tratamento de time out e retransmisso, quanto do
ponto de vista lgico, com aviso ao nvel superior de uma transmisso bem sucedida
ou abortada por excesso de colises.
Detetor de link: Gera o sinal de reconhecimento do estado de uma conexo de rede,

bem como reconhece e sinaliza o estado atual da conexo de rede, baseado no sinal
gerado pelo equipamento remoto.
Codificador / decodificador Manchester: Executa a codificao do sinal digital a

ser transmitido no cabo de rede, segundo o cdigo Manchester, e na recepo de um
sinal da rede executa a sua decodificao.
Gerador / verificador de CRC: Mdulo que calcula o CRC de um pacote que deve
ser enviado pela rede, adicionando-o no local correto. No retorno de um pacote da
rede executa a verificao do CRC, descartando dados defeituosos.
Reconhecimento de endereo fsico: O reconhecimento do endereo de destino de

um pacote que chega automaticamente executado por este mdulo, com o descarte
de pacotes que no sejam destinados ao hospedeiro local.
Montagem do pacote: O pacote de dados a ser enviado, previamente colocado na

memria do controlador, montado de forma a poder ser enviado com o seu
prembulo e CRC adicionados. Na recepo o prembulo descartado e o CRC
verificado.
Fica a cargo do projetista a montagem do pacote de dados a ser enviado, incluindo os

endereos MAC de destino e origem, pertencentes ao cabealho Ethernet, bem como o
cdigo do protocolo carregado no quadro. A seguir atravs de operaes de DMA
prprias do controlador os dados devem ser armazenados na memria interna para
processamento e envio pelo controlador de rede. As operaes de envio para a memria
45
local do controlador de um pacote que deve ser enviado pela rede, e a retirada de um
pacote que chega foram abordadas em detalhes anteriormente neste captulo.
2.4.2 A Implementao do Protocolo

Baseado no exposto no item anterior, notamos que pouco fica a ser feito no
processamento dos dados do quadro Ethernet, devido grande automao que o
controlador de rede utilizado proporciona.
Como resultado a funo que prepara o cabealho Ethernet bastante simples, como
podemos observar na figura 2.14 a seguir.
Incio
MAC Dest
?
S
Prepara MAC destino
Prepara MAC origem
Prepara protocolo
< 46 bytes
?
Enchimento
N
Envia Pacote
Fim
FIGURA 2.14 Fluxo do protocolo Ethernet
Inicialmente verificado se o endereo fsico de destino foi validado pelo protocolo

ARP, atravs de seu cache. Caso negativo o pacote no poder ser enviado devido
falta do endereo do hospedeiro de destino. Caso o endereo esteja validado, ento o
restante do cabealho Ethernet preenchido, e a seguir verificado o tamanho da rea
de dados, que nunca dever ser menor que 46 bytes. No caso da rea de dados possuir
menos que 46 bytes ento um enchimento com brancos (0x20) executado com o
objetivo de atingir o tamanho mnimo de um quadro Ethernet. O prximo passo
remeter o pacote acabado para o controlador de rede, com o uso da funo
EnviaPct().
A funo EnviaPct()executa o DMA apropriado visando colocar o pacote na rea de
memria local do controlador, de forma que este execute os processos necessrios ao
correto encaminhamento do pacote pela rede.
46
2.5 O Protocolo ARP (Address Resolution Protocol)

A falta de padronizao das camadas fsica e de enlace de dados pelo TCP/IP pressupe
a utilizao de abstrao destas camadas pelos protocolos de nveis superiores. Uma das
formas desta abstrao a utilizao de endereos de nvel alto para especificar os
hospedeiros pertencentes rede, independendo totalmente da forma de endereamento
implementada no hardware. Para o TCP/IP, cada hospedeiro possui um endereo IP
nico, mas de forma alguma, este endereo pertence ao hardware, podendo facilmente
ser utilizado por diversos hospedeiros, desde que no ao mesmo tempo. Isto , o
endereo IP um endereo da camada de rede, que normalmente implementada em
software, e portanto pode ser facilmente alterado. Por outro lado, o endereo de
hardware fixo, como por exemplo, no caso do padro Ethernet so seis bytes gravados
em fbrica diretamente na interface de rede.
Por este motivo necessria a adoo pela pilha TCP/IP de um mecanismo eficiente de
mapeamento de endereos IP em endereos de hardware e, neste sentido, foi
padronizado pela RFC 826 [PLU 82] um protocolo de resoluo de endereos IP em
endereos de hardware denominado ARP.
Conforme citado anteriormente, visando a economia de recursos na implementao em
hardware do cdigo resultante, a implementao do protocolo ARP ficou restrita ao
cache ARP e ao lado servidor, ou seja, aquele que responde s solicitaes de resoluo
de endereo. Para atingir tal objetivo, o software anteriormente implementado
(pingador) sofreu algumas melhorias significativas do ponto de vista de sua
funcionalidade.
2.5.1 A Resposta ARP

Partindo do princpio de que o sistema desenvolvido por esta aplicao no executar,
em momento algum, o papel de cliente, em qualquer dos nveis do protocolo TCP/IP,
fica claro que o comportamento da implementao ser apenas reativo, ou seja servidor.
Portanto, os aspectos da pilha de protocolos relativos ao lado solicitante (cliente) foram
ignorados.
Com este enfoque consegue-se atingir o objetivo de economia de recursos, uma vez que
grande parte do cdigo previsto pelos padres do protocolo no so implementados.
Esta estratgia permite que o sistema como um todo tenha seu tamanho reduzido,
viabilizando sua integrao em hardware.
O ARP possui trs blocos funcionais: entrada, sada e gerenciador de cache. Alm
destes blocos, existe uma estrutura de memria que implementa o cache ARP, onde
baseada toda a funcionalidade do protocolo, sendo, fundamentalmente, uma tabela
mantida em memria com o mapeamento de endereos IP para endereos de hardware,
com uma entrada para cada hospedeiro da rede com endereo validado pelo ARP.
Existem tambm dados adicionais pertinentes a cada entrada da tabela como, por
exemplo, tipo de hardware (Ethernet, Token Ring, etc.), tipo de protocolo de alto nvel
(IP ou outro qualquer), tamanhos dos endereos utilizados pelos protocolos envolvidos,
tempo de vida (TTL) desta entrada entre outros. A figura 2.15 a seguir ilustra o formato
do pacote ARP.
47
Tamanho em bytes
Tipo de Hardware
Tipo de Protocolo
Tamanho do Endereo de Hardware
Tamanho do Endereo do Protocolo
Operao
Endereo de Hardware de Origem
Endereo IP de Origem
Endereo de Hardware de Destino
Endereo IP de Destino
FIGURA 2.15 - Formato dos dados dos protocolos ARP.
Os campos Tipo de Hardware e Tipo de Protocolo definem qual o hardware utilizado

pela interface de rede e qual o protocolo de alto nvel que est utilizando o ARP,
denotando a diversidade de aplicao do ARP que, desta forma, poder ser utilizado
com qualquer combinao de protocolos de nvel dois e trs (ISO OSI) [ISO 94]. A
seguir, dois campos de um byte cada especificam o comprimento em bytes do endereo
implementado nestes protocolos, definindo, portanto, o tamanho dos quatro ltimos
campos do quadro. No caso do Ethernet e IP, estes campos possuem, respectivamente,
seis e quatro bytes. O campo Operao define o tipo da mensagem que pode ser: 1
Requisio ARP, 2 Resposta ARP.
Em uma requisio ARP, o hospedeiro origem preenche seus endereos na mensagem e
adiciona o endereo IP do destino, o qual deseja descobrir o endereo de hardware,
enviando a solicitao para todos os hospedeiros, no nvel de enlace de dados. Na
resposta requisio, o hospedeiro de destino preenche seu endereo de hardware,
trocando os pares de endereo (origem por destino), altera a operao para resposta
ARP e envia um pacote diretamente ao hospedeiro de origem.
A rotina responsvel pela resposta uma solicitao ARP proveniente da rede
executada pela funo ArpResp()conforme ilustra a figura 2.16 a seguir. Ao receber
uma solicitao o chaveador central que encontra-se na funo principal do programa
faz trs verificaes sobre o pacote que chega:
1- Se o pacote Ethernet carrega em sua rea de dados um pacote ARP, verificando o
campo Tipo de Protocolo Ethernet.
2- Se o endereo IP de destino contido no pacote ARP confere com o endereo IP
local, ou seja se o pacote destina-se ao hospedeiro local.
3- Se o pacote ARP uma solicitao, tendo em vista que as respostas ARP no so
tratadas pelo lado servidor, e o lado cliente no est implementado.
A seguir a funo de resposta ARP chamada se encarregando de todo o processamento
dos dados que chegaram, visando a gerao de uma resposta adequada ao solicitante.
A primeira ao a busca do endereo IP do hospedeiro que gerou a solicitao na
tabela ARP, visando adicionar o par Endereo IP, endereo MAC na tabela caso no
exista. A seguir o tempo de vida (TTL) desta entrada ajustado em 11 minutos. De
48
posse dos endereos de origem a resposta ao solicitante pode ser elaborada, e a seguir
encaminhada funo EtherResp(), para encapsulamento no pacote Ethernet e
posterior envio para a rede.
Na figura 2.16, pode-se observar o fluxo de operaes envolvido na funo de gerao
de resposta ARP.
ArpResp( )
Copia endereo IP de
origem
Encontrou no
cache?
N
Adiciona a entrada no
cache
S
Ajusta TTL para 11 min
Prepara pacote de
resposta
Envia para Ethernet
Fim
FIGURA 2.16 Fluxo da funo de resposta ARP.
2.5.2 A gerncia do cache ARP

A tabela que implementa a memria ARP utilizada por este sistema TCP/IP bastante
simples, tendo em vista as vrias opes de campos de dados disponveis, previstos no
padro. Os campos selecionadas para cada registro que ser inserido nesta tabela so:
1- Endereo IP do hospedeiro destino.
2- Endereo MAC do hospedeiro destino
3- TTL desta entrada
A cada solicitao de resoluo de endereo que o hospedeiro local receba, como
primeira tarefa ser feito o acrscimo dos endereos (MAC e IP) do hospedeiro que
originou a solicitao no cache, caso ainda no exista tal entrada. Com esta estratgia, a
comunicao que se estabelecer a seguir entre os protocolos de mais alto nvel, fluir
sem necessidade de novas resolues de endereo IP em endereo MAC, tendo em vista
que estes j encontram-se resolvidos na tabela local.
O tempo de vida de uma entrada especificado em 10 minutos, caso esta entrada esteja
sendo utilizada regularmente pelos protocolos de nvel superior, ou de 2 minutos caso
49
deixe de ser utilizada. Aps estes tempos uma nova solicitao de resoluo de endereo
dever ser enviada rede, visando a atualizao da entrada no cache.
Como o sistema implementado no contempla o lado cliente, gerador de solicitaes de
resoluo de endereos, a estratgia utilizada foi colocar o tempo de vida de cada
entrada do cache local com um minuto a mais do que o maior tempo de TTL permitido
no protocolo ARP.
Segundo o protocolo, o tempo mximo permitido para a validade de uma entrada ARP
no cache de 10 minutos, desde que esta entrada esteja em uso regular pelos protocolos
superiores. Portanto cada entrada no hospedeiro local ter o seu TTL fixado em 11
minutos, forando assim com que os hospedeiros que se conectam ao hospedeiro local
sempre sejam obrigados a solicitar a resoluo de endereos, liberando o sistema local
desta tarefa. Com esta estratgia simples pode-se dispensar completamente o lado
cliente do protocolo, atingindo o objetivo de economia de recursos.
A funo que desempenha o papel de gerncia da tabela ARP local a ArpCache(),
que resume suas aes em duas:
1- Busca na tabela por uma entrada j resolvida, e vlida, de um determinado endereo
IP, para o qual se pretenda enviar um datagrama.
2- Retorno do ndice de entrada de uma entrada vazia, ou da entrada mais antiga (caso
a tabela j se encontre cheia), caso o endereo IP pretendido ainda no existir como
entrada vlida.
Esta funo bastante simples, visto que a funo de gerao de resposta ARP se
encarrega do acrscimo das novas entradas que eventualmente cheguem pela rede. A
figura 2.17 ilustra o fluxo da funo de gerncia do cache local.
ArpCache( )
Endereo IP
vlido?
S
Encontrou no
cache?
Retorna a entrada
encontrada
N
Retorna uma entrada
vazia ou a mais antiga
Fim
FIGURA 2.17 Fluxo da funo de procura na tabela ARP.
50
2.6 O Protocolo IP (Internet Protocol)

O protocolo IP o responsvel pelo roteamento de datagramas entre as diversas redes
componentes de uma malha de redes, tendo como uma de suas caractersticas a falta de
confiabilidade, uma vez que no prov mecanismos de deteco ou correo de erros de
transmisso para os dados que carrega. Para atingir tal objetivo, o protocolo mantm
uma tabela de roteamento em cada hospedeiro e roteador, que, trabalhando de forma
cooperativa, encaminham um datagrama de uma origem at o seu destino, mesmo que
para isto o datagrama tenha que atravessar diversas redes que no as da origem ou de
destino. O datagrama IP diretamente encapsulado no quadro de nvel de enlace de
dados, onde, no caso desta implementao ser utilizado o padro Ethernet.
Para prover a confiabilidade necessria s aplicaes de rede, como o caso do trabalho
aqui desenvolvido, a prxima camada de protocolo (TCP) fornecer todos os
mecanismos de deteco e correo de erros, como podemos notar no desenvolvimento
desta camada mais adiante.
Padronizado pela RFC 791 [POS 81], o protocolo IP apresenta o datagrama com o
formato ilustrado na figura 2.18.
Tamanho em bytes
1~8
9 ~ 16
17 ~ 24
25 ~ 32
33 ~ 40
41 ~ 48
Verso
Tamanho do Cabealho
Tipo de Servio
Tamanho do Datagrama
Identificao
Flags
Deslocamento do Fragmento
TTL
Protocolo
Soma de Verificao do Cabealho
Endereo IP de Origem
Endereo IP de Destino
Opes e Enchimento
Dados
FIGURA 2.18 - Formato do datagrama IP
O campo Verso carrega a informao de verso do IP utilizado no datagrama e, caso

seja diferente da verso presente no hospedeiro, ento o datagrama deve ser descartado
(a verso atual a quatro). Tamanho do Cabealho especifica o comprimento da rea de
cabealho em mltiplos de 32 bits.
O campo Tipo de Servio especifica como o IP deve tratar o datagrama. Os primeiros
trs bits formam a precedncia onde sete a maior e zero a normal, permitindo a
priorizao de datagramas com precedncia maior. Os trs bits seguintes sugerem como
o datagrama deve ser roteado, onde o quarto bit solicita intervalo baixo, o quinto bit
Taxa de transferncia alta e o sexto bit alta confiabilidade. Nem sempre possvel ao
roteador atender a esta demanda, portanto, comum implementaes que no as levem
em considerao at por questes de impossibilidade fsica de atendimento.
51
Tamanho do Datagrama especifica o tamanho total do datagrama em bytes,
Identificao identifica um datagrama univocamente e, no caso da necessidade de
fragmentao por motivo de uma rede com pequeno MTU (Maximum Transfer Unit),
cada fragmento pertencente a um determinado datagrama inicial contm a mesma
identificao. O campo Flags contm trs bits e controla a fragmentao, o primeiro bit
no utilizado, o segundo bit sinaliza se o datagrama pode ou no ser fragmentado, o
terceiro bit indica se o fragmento intermedirio ou se o ltimo fragmento de um
datagrama original. O campo Deslocamento do Fragmento de 13 bits identifica o
deslocamento dos dados originais que o fragmento atual carrega em mltiplos de oito
bytes, iniciando em zero at que o ltimo fragmento sinalize um deslocamento igual ao
tamanho do datagrama original. O campo Protocolo define qual o protocolo est
encapsulado nos dados do datagrama, Soma de Verificao um checksum da rea de
cabealho IP, TTL sinaliza o tempo mximo que o datagrama pode permanecer
transitando entre redes. Cada roteador o decrementa e, atingindo zero o datagrama
descartado. Os campos Endereo IP de Origem e Endereo IP de Destino especificam a
origem e o destino do datagrama e no so alterados, medida que o datagrama
roteado entre as redes.
O campo Opes e Enchimento no obrigatrio, mas existindo, possui comprimento
entre um byte at o tamanho mximo do cabealho limitado pelo campo Tamanho do
Cabealho e sempre deve ter comprimento mltiplo de 32 bits, da a necessidade do
enchimento. Este campo utilizado para testes e depurao da rede e, por fim seguem
os dados encapsulados.
2.6.1 As Simplificaes Utilizadas

Por questes de economia de recursos, a implementao do protocolo IP no segue
todas as possibilidades previstas pela RFC, mas apresenta vrias limitaes que,
empregadas de forma consistente, no prejudicam de forma alguma o sistema como um
todo.
Por se tratar de um hospedeiro, o sistema no implementa os itens referentes ao
roteamento de datagramas, uma vez que tais rotinas so totalmente prescindveis.
Visando atingir o status de roteador, o servidor de dados deveria possuir pelo menos
duas interfaces de rede, ou seja, conectar-se fisicamente a pelo menos duas redes, o que
no o escopo deste trabalho. Como resultado desta simplificao muitos recursos de
hardware foram economizados, e do ponto de vista do software, muitas rotinas
complexas deixaram de ser desenvolvidas. O sistema proposto comporta-se como um
hospedeiro servidor de dados, possui uma nica interface de rede, e reativo, isto ,
somente responde quando solicitado por um cliente externo. Desta forma o roteamento
de datagramas completamente dispensvel.
Outra simplificao utilizada no nvel do protocolo IP quanto fragmentao de
datagramas. Segundo o padro, quando um datagrama atinge uma rede com MTU
menor que o seu tamanho total, o roteador limtrofe deve quebr-lo em partes menores,
a fim de atingir o tamanho correto para atravessar a rede. Desta forma o hospedeiro
destino do datagrama partido tem que possuir a capacidade de remontar o datagrama
original, com o fim de recuperar seus dados corretamente.
Tendo por premissa que o nvel de enlace de dados utilizado no desenvolvimento do
trabalho foi o padro Ethernet, existe a possibilidade de se transportar quadros com at
52
1500 bytes. Contribuindo com isto a quantidade de dados enviados pelo nvel de
aplicao (HTTP) devero normalmente estar bem abaixo disto, ento a capacidade de
remontagem de datagramas IP foi completamente desconsiderada. Esta posio poder
ser reconsiderada no caso da utilizao do sistema proposto em conexes com a
Internet, onde redes com pequeno MTU podem ser factveis, conduzindo desta forma
fragmentao.
2.6.2 A Implementao do Protocolo IP

Por conta das simplificaes utilizadas, a implementao do protocolo IP ficou bastante
compacta, principalmente devido caracterstica reativa do sistema. Desta forma, ao
receber uma solicitao de um cliente, so executadas algumas verificaes de
integridade e qualidade do cabealho, e a seguir uma resposta imediatamente montada
e remetida ao cliente.
A figura 2.19 ilustra o fluxo da rotina que executa a montagem e despacho do
datagrama IP.
Inicio
Montagem do cabealho
do datagrama
Clculo do Check Sum

do cabealho
Consulta a tabela ARP

pelo endereo MAC
Encapsula no quadro
Ethernet
Fim
FIGURA 2.19 O fluxograma da rotina IP
Inicialmente so preparados os campos do cabealho com valores fixos, tais como

verso, tipo de servio, os campos pertinentes a fragmentao, TTL, entre outros. Aps
a preparao inicial do cabealho, o campo de soma de verificao zerado, e a funo
de clculo de CheckSum chamada preenchendo o campo com o valor adequado.
Aps o cabealho estar completamente montado, executada uma consulta tabela
ARP em memria visando obter o endereo fsico do hospedeiro destino do datagrama.
Isto conseguido atravs da chamada da funo ArpCache().
Por fim, o datagrama dever ser encapsulado no quadro de nvel de enlace de dados,
com a utilizao da funo de montagem do cabealho Ethernet EtherResp().
53
2.6.3 O Protocolo ICMP (Internet Control Message Protocol)

O protocolo ICMP responsvel pelo envio de mensagens administrativas na rede,
comunicando erros ocorridos durante o roteamento de datagramas, bem como dados de
ajuste ou configurao para o hospedeiro originador do datagrama. Os roteadores
utilizam o ICMP para a comunicao de datagramas descartados, congestionamentos,
TTL excedido entre outros. Os hospedeiros o utilizam para a atualizao de rotas na
tabela de roteamento, ajuste de horrio, teste de acessibilidade etc.
Na interligao em redes, um datagrama flui de roteador em roteador at atingir seu
destino final. Se, durante este percurso, houver algum problema que inviabilize a
viagem do datagrama, o roteador que tomou a ao de descarte deve enviar um
mensagem ICMP indicando a causa do problema ao hospedeiro de origem, para que
esse tome as providncias necessrias. Deve-se notar que este protocolo no serve para
a troca de mensagens de erro entre roteadores, porque, por ser diretamente encapsulado
em um datagrama IP, os endereos disponveis para envio da mensagem so unicamente
os de origem e de destino.
O protocolo ICMP padronizado pela RFC 792 [POS 81a], e os seus dados so
diretamente encapsulados em um datagrama IP, com a finalidade de poder atravessar as
interligaes de rede e atingir o hospedeiro que originou o datagrama com problema,
rompendo, desta forma, a barreira da rede local.
A mensagem ICMP possui um cabealho e, dependendo do tipo da mensagem, a rea de
dados com tamanho e contedo varivel, conforme ilustra a figura 2.20.
Tamanho em bits
1~8
9 ~ 16
17 ~ 24
25 ~ 32
33 ~ 40
41 ~ 48
Tipo
Cdigo
Soma de verificao
Dados
FIGURA 2.20 - Formato da mensagem ICMP
Os campos Tipo e Cdigo especificam a mensagem carregada pelo quadro, e, a partir

da, a rea de dados ser preenchida de acordo. O campo Soma de Verificao executa
um checksum somente sobre a rea de dados da mensagem.
Com o intuito de simplificao do cdigo gerado, a maioria das opes de tipos de
mensagem, disponveis no protocolo foram ignoradas, ficando apenas o teste de
conectividade via rede, conhecido como eco.
As mensagens do tipo 0 e 8 especificam resposta e requisio de eco,
respectivamente, utilizadas para localizao de problemas na rede. O campo
Identificador caracteriza uma determinada solicitao e o campo Nm. de seq., a
seqncia das mensagens nesta solicitao. Na rea de dados, opcionalmente, a
requisio pode colocar qualquer seqncia de caracteres (o tamanho no fixo) que
devero ser repetidos pela resposta.
54
2.6.4 A Implementao do Protocolo ICMP

O cdigo resultante do protocolo ICMP , de forma semelhante ao protocolo IP,
bastante simples, como se pode notar na figura 2.21.
A primeira ao tomada pela rotina a verificao da soma de verificao presente no
cabealho do datagrama que chega do cliente, com o intuito de deteco de um possvel
pacote defeituoso. Caso a soma de verificao no confira com a gerada pela funo de
verificao (CheckSum()), o pacote imediatamente descartado.
Caso a requisio de eco recebida pela rede do cliente esteja ntegra, ento a resposta a
esta requisio montada, iniciando pela preparao do cabealho ICMP, que bastante
simples. Deve ser tomado cuidado com os campos de identificao e seqncia, com o
fim de que o cliente consiga distinguir esta resposta de outras, que possivelmente
cheguem ao mesmo tempo de outros hospedeiros, e desta forma tenha sucesso na
associao de diferentes solicitaes e respostas de eco.
A seguir os dados presentes na requisio de eco que chega devem ser copiados na
resposta que est sendo montada, com o fim de envio para o cliente, posto que a rea de
dados deve ser igual entre requisio e resposta.
Inicio
CheckSum
Correto?
S
Montagem do cabealho
ICMP
Cpia dos dados

recebidos
Clculo do CheckSum
Encapsula no quadro
Ethernet
Fim
FIGURA 2.21 Fluxograma da rotina ICMP
Por fim o clculo da soma de verificao do novo pacote executada e colocada no

campo apropriado. A partir deste momento o pacote ICMP pode ser encapsulado no
datagrama IP com o fim de ser remetido, pela interligao de redes, at atingir o cliente
que iniciou a solicitao.
55
2.7 O Protocolo TCP (Transmission Control Protocol)

O TCP o protocolo mais complexo da pilha TCP/IP, padronizado pela RFC 793 [POS
81b], e apresenta toda a funcionalidade necessria ao gerenciamento de uma conexo
fim-a-fim. Localiza-se no nvel de transporte, sendo utilizado sempre que as aplicaes
necessitarem maior confiabilidade na infra-estrutura pouco confivel fornecida pelo IP.
O TCP utiliza um sistema de multiplexao de dados entre as diversas aplicaes
origem e destino, fornecido pela abstrao das portas. Alm disto, muitos artifcios so
utilizados para que as aplicaes nos extremos da comunicao no percam tempo com
rotinas voltadas confiabilidade do ambiente de rede. Exemplos disto so a utilizao
de esquemas de deteco e correo de erros, caractersticas de previso e preveno de
congestionamentos no trfego de segmentos TCP pela interligao de redes e a
utilizao de rotinas de otimizao da vazo dos dados pela rede.
Os dados que fluem de forma bidirecional em uma conexo TCP e possuem a
caracterstica de fluxo de bits, ou seja, o protocolo no toma conhecimento de estruturas
de dados criadas pela aplicao, tudo remetido de ponta a ponta como um fluxo de
bytes contnuo, sem qualquer tipo de demarcadores.
O cabealho de um segmento TCP pode ser visto na figura 2.22, e diretamente
encapsulado no datagrama IP, que conter o valor 6 no campo Protocolo, indicando
que este datagrama carrega um segmento TCP na sua rea de dados.
Tamanho em bytes
1~8
9 ~ 16
17 ~ 24
25 ~ 32
Porta de Origem
Porta de Destino
Seqncia
Reconhecimento
Tamanho do Cabealho
Reservado
Bits de Cdigo
Janela
Soma de Verificao
Ponteiro de Urgente
Opes e Enchimento
Dados
FIGURA 2.22 - Formato do cabealho do TCP
Os campos Porta de Origem e Porta de Destino contm, respectivamente, os endereos

das portas de protocolo de origem e de destino das aplicaes finais. Seqncia indica
em qual posio dos dados transmitidos pela origem se encontram os dados contidos
neste segmento. Reconhecimento indica o prximo byte que a origem espera receber a
seguir do fluxo de dados que flui do destino para a origem. Tamanho do Cabealho
um inteiro que contm o tamanho do cabealho deste segmento, incluindo as opes,
caso existam, e possui o tamanho de quatro bits, sinalizando o tamanho do cabealho
em mltiplos de 32 bits. A seguir, encontram-se dois campos de seis bits, o primeiro
56
reservado para aplicao futura e o segundo contm seis indicadores, conforme a tabela
2.12.
TABELA 2.12 - Significado dos indicadores no cabealho TCP
Indicador
Significado
URG
O campo Ponteiro de Urgente vlido
ACK
O campo Reconhecimento vlido
PUSH
Solicita a entrega imediata dos dados aplicao destino
RESET
Reinicializar a conexo
SYN
Sincronismo de nmeros de seqncia indicado no campo Seqncia
FIN
O emissor encerrou suas transmisses
O TCP no hospedeiro de origem informa ao destino o tamanho mximo de sua rea de

memria destinada recepo de dados atravs do campo Janela. A Soma de
Verificao feita com a incluso de um pseudo cabealho, onde o campo Protocolo
conter o valor seis. O campo Ponteiro de Urgente, quando vlido, aponta para o final
dos dados urgentes que o segmento carrega, indicando que estes dados devem ser
imediatamente entregues aplicao de destino.
O campo Opes, quando existir, deve ser mltiplo de 32 bits, da a necessidade de um
enchimento. A principal funo deste campo a negociao para o tamanho mximo do
segmento (MSS) utilizado nesta conexo. Finalmente, vem a rea de dados do segmento
que conter o tamanho mximo igual ao MSS subtrado do tamanho do cabealho TCP.
2.7.1 Simplificaes Utilizadas no TCP

Algumas simplificaes foram adotadas durante o desenvolvimento do protocolo TCP,
visando otimizar a utilizao de recursos. O processo de estabelecimento e finalizao
de uma conexo TCP bastante complexo, de acordo com o previsto na RFC, e embora
no possa ser simplificado de forma expressiva sob pena de fugir do seu escopo, pode
ter algumas poucas alteraes.
O processo de estabelecimento da conexo, previsto para possuir trs etapas, foi
mantido inalterado, tendo em vista sua simplicidade. O padro prev situaes de erro
durante esta fase, como por exemplo, a perda de pacotes, que por simplicidade no
foram codificadas nesta implementao. Para resolver qualquer impasse durante o
estabelecimento da conexo TCP foi implementado um temporizador, que reinicializa a
conexo no caso de vencer o seu prazo.
De forma semelhante, o processo de finalizao da conexo foi simplificado, sendo
previsto apenas a finalizao em duas etapas, uma para cada sentido do fluxo de dados.
Assim, so utilizados dois pacotes, um de solicitao de finalizao e um de
reconhecimento. De forma semelhante ao estabelecimento da conexo, a finalizao no
prov os esquemas de erro estabelecidos pelo RFC.
Aps o estabelecimento de uma conexo de forma adequada, o cliente deve fazer uma
solicitao HTTP conhecida por get, quando o servidor retornar uma pgina HTTP
previamente selecionada, armazenada no servidor. Esta pgina deve ser simples e de
contedo esttico preferencialmente, no inviabilizando o contedo dinmico, caso
necessrio. Toda a preocupao gira em torno do fato de que a aplicao resultante deve
ser a menor possvel, visando economia na rea de silcio do hardware final.
57
2.7.2 A Mquina de Estados TCP

De acordo com a RFC 793, uma mquina de estados deve ser implementada visando o
gerenciamento da conexo TCP a uma determinada porta. Conforme mencionado
anteriormente, so previstas muitas situaes por esta mquina, isto , estados e
condies para a troca entre estados. Ainda so previstas situaes de erro que devem
ser tratadas durante as transies de estados, em vrios nveis da mquina de estados
TCP.
Com o fim de executar os processos envolvidos na inicializao, manuteno e
finalizao de uma conexo TCP, a mquina de estados implementada sofreu algumas
simplificaes, como pode ser notado na figura 2.23.
Incio
Estado =
Ouve
Recebe
SYN
Envia
FIN
Tempo de conexo
esgotado
Envia SYN ACK.

Estado =
SYN ACK Enviado
Envia ACK.
Recebe
ACK
Envia ACK.
Estado =
FIN recebido
Recebe
FIN
Estado =
Conectado
Recebe
FIN
Envia HTTP e
FIN
Estado =
FIN enviado
FIGURA 2.23 Mquina de estados simplificada.
Durante o estabelecimento de uma conexo TCP, inicializado um temporizador e

ajustado em 15 minutos. Durante este perodo de tempo, o servidor aguarda o
recebimento de um pacote SYN. Caso receba o pacote pretendido, ento o estado passa
a ser Conectado, caso contrrio o estado passar a ser Ouve novamente.
Aps uma conexo estabelecida com sucesso, durante o estado Conectado, existir a
fase de troca de dados entre cliente e servidor, que de forma bastante simples ser uma
requisio HTTP get enviada pelo cliente, seguida por uma pgina HTML (Hiper Text
Markup Language) retornada pelo servidor. A seguir o servidor envia um segmento de
finalizao FIN com o fim de encerrar a conexo corrente, no sentido servidor cliente.
Aps receber o reconhecimento desta finalizao o estado da mquina TCP passar a
ser FIN enviado, e aguardar o cliente encerrar o seu canal da conexo.
O lado cliente dever seguir o mesmo processo executado pelo servidor para finalizar o
seu canal da conexo. Aps o encerramento com sucesso de ambos canais da conexo
TCP, a conexo propriamente dita ser finalizada, retornando ao estado original Ouve.
Desta forma os recursos consumidos por esta conexo sero liberados visando sua
utilizao por uma nova conexo.
Embora no esteja explcito no diagrama de estados, a qualquer momento a conexo
pode ser encerrada utilizando-se o bit de RESET do TCP.
58
A utilizao de conexes rpidas, isto , conecta, remete a pgina HTML e finaliza,
diminui a necessidade de gerenciamento de grandes quantidades de conexes ativas,
reduzindo as necessidades de recursos consumidos pelo servidor, com memria e
capacidade de processamento.
2.7.3 O Cdigo TCP

A figura 2.24 a seguir representa o fluxograma do cdigo implementado para a
execuo do protocolo TCP.
Inicialmente o pseudo cabealho TCP gerado com o fim de clculo da soma de
verificao do pacote que chega, que caso contenha erro, o processo de resposta
abortado imediatamente.
Para o caso de um pacote que chega do cliente correto, verificada a porta da conexo
pretendida. Caso exista, ento o fluxo remetido para a mquina de estados TCP, que se
encarrega do restante da lgica envolvida no gerenciamento das conexes ativas. Caso o
pacote remetido pelo cliente no pertena a alguma conexo em processo, ento deve
ser um pedido de estabelecimento de uma nova conexo TCP. Qualquer outra hiptese
invlida ocasionando o fim da execuo do processo TCP.
A mquina de estados TCP implementa os processos descritos no item anterior, que
disserta especificamente sobre a mquina de estados utilizada na corrente
implementao.
59
Incio
Prepara
pseudocabealho
CheckSum
Correto?
S
N
Erro !
Solicitao
SYN?
Conexo
Ativa?
S
Prepara nova
conexo
Falhou SYN
ACK?
Ajusta para enviar novo

SYN ACK
Estado
Ouve?
Prepara cabealho
SYN ACK
Ajusta time out para

recepo do ACK
Estado =
SYNEnv
Estado
SYNEnv?
SYN ACK,
Time out?
Estado =
Conex
Estado
Conex?
ACK,
GET?
Envia FIN,
Estado = FIN
Chama
HTTP
Estado
FIN?
N
ACK
?
Estado1 =
FINLoc
S
Estado =
Ouve
FINLoc e
FINRem?
Recebido
FIN?
Envia ACK,
Estado2 = FINRem
N
Erro !
N
Recebido
RES?
Fim
FIGURA 2.24 Fluxo do protocolo TCP.
Estado =
Ouve
60
3 A Gerao de um ASIP
A tendncia natural de miniaturizao e portabilidade dos sistemas eletrnicos atuais

conduz a algumas definies de projeto baseado na orientao do estado da arte da
tecnologia. Baseado neste fato, e em vrios trabalhos efetuados na tentativa de apontar
ou proporcionar ferramentas e mtodos para a sntese eficiente de hardware e software
para aplicaes especficas, este trabalho busca uma soluo compacta, de simples
emprego e de custo acessvel, visando a aplicabilidade praticamente imediata da soluo
aqui apontada.
Um trabalho que foi utilizado, visando a gerao em hardware do sistema aqui proposto,
a anlise e sntese de software e hardware dedicado para aplicao especfica
denominado System as Software and Hardware in Microcontrollers (SASHIMI). Esta
ferramenta ser utilizada neste trabalho visando a gerao de um processador dedicado
com um pequeno conjunto de instrues, bem como o respectivo software que executar
a aplicao fim, ou seja a pilha TCP/IP.
3.1 A Opo por um Processador Dedicado

Os sistemas embarcados orientam-se pela necessidade de leveza, robustez, consumo,
adequabilidade, entre outras caractersticas, muitas vezes conflitantes. Baseado no
trabalho elaborado por Srgio Ito [ITO 2000], neste ambiente os microcontroladores
dominam o cenrio, e a tendncia de que se mantenham neste segmento de mercado,
principalmente devido a algumas caractersticas interessantes como:
Devido ao seu normalmente pequeno conjunto de instrues, no existe o custo

adicional de hardware exigido pelas instrues desnecessrias aplicao proposta;
Fornece um conjunto computacional praticamente completo com unidade de

processamento, memria, entradas e sadas, conversores analgico / digital, entre
outras funes;
So pensados de forma a fornecer apenas a quantidade de memria, e outros

recursos, necessrios s pequenas aplicaes em que sero empregados;
Apresentam programabilidade simplificada, principalmente devido a uma ampla

gama de ferramentas de auxlio ao programador, proporcionando facilidades de
escolha de linguagem de programao como Assembler, C, Pascal, entre outras;
Com a presso do mercado, novas funes so constantemente adicionadas ao

hardware, simplificando o desempenho de tarefas complexas como por exemplo a
adio de ncleos de processamento digital de sinais (DSP), ou a possibilidade de
utilizao de caractersticas muito desejveis na tecnologia embarcada, como o
controle do consumo de energia do dispositivo.
61
Mas embora sejam muitas as qualidades apresentadas pelos microcontroladores, uma
caracterstica fundamental: o custo reduzido. Este custo derivado principalmente da
adequabilidade do conjunto hardware / software aplicao fim, e dos volumes
envolvidos.
Considerando-se todas as vantagens apresentadas quando da utilizao de
microcontroladores em sistemas embarcados, deve-se levar em conta uma importante
caracterstica que pode ser agregada ao dispositivo visando otimizar ainda mais seu
conjunto de vantagens, ou seja, a implementao somente das instrues realmente
necessrias aplicao. Com este artifcio gera-se um processador com instrues
especficas para a aplicao (Application Specific Instuction set Processor - ASIP), que
apresentar o menor custo do conjunto hardware, embora o desenvolvimento de
software fique bastante limitado, uma vez que o carter de aplicabilidade ampla de um
conjunto completo de instrues deixa de existir. Devido a este fato, deve ser bastante
criteriosa a definio do conjunto de instrues que ser implementado no sistema.
Durante a fase de elaborao do software aplicativo para o sistema embarcado com a
utilizao de ASIPs, fundamental a utilizao de um compilador adequado ao
conjunto de instrues proporcionado pelo processador, recaindo sobre este ponto a
principal desvantagem desta abordagem. Como conseqncia, o programador fica
basicamente limitado elaborao de programas em Assembler, abrindo mo da
reutilizao, e com a desvantagem da difcil manuteno do cdigo resultante.
Conforme [KRE 97], quatro abordagens de soluo podem ser implementadas na
tentativa de resolver os problemas especficos gerados por uma determinada aplicao
fim. A adequabilidade de uma ou outra das possveis solues depende de uma anlise,
por muitas vezes complexa do ambiente da aplicao, de sua exeqibilidade, custo,
disponibilidade de ferramentas, prazos, entre outros tantos fatores que por ventura
surjam durante o desenvolvimento do sistema.
A primeira aproximao o desenvolvimento de um circuito integrado especfico para a
aplicao fim, onde a principal desvantagem o custo de desenvolvimento, mas por
outro lado apresenta, sem dvida, o melhor desempenho.
A segunda abordagem a elaborao de um processador especfico para a aplicao,
que, conforme j discutido, possui um conjunto de instrues reduzido e totalmente
voltado para a aplicao fim. Com esta abordagem o custo de desenvolvimento do
hardware grande, tendo em vista a sua adequao aplicao, mas o custo final do
sistema ser reduzido, uma vez que os elementos desnecessrios no sero
implementados, reduzindo assim o custo do hardware final.
Outra possibilidade o projeto resultante do projeto conjunto de software e hardware
onde ao processador central ser adicionado algum hardware especfico voltado para a
aplicao fim. Com esta aproximao, o desempenho final do sistema ser prximo do
processador de aplicao especfica, com a vantagem da programao fcil.
Por fim, h a soluo clssica do processador de propsito geral com a conduo do
problema totalmente orientada ao software. As vantagens do ponto de vista de
programabilidade so grandes e poderosas, mas com o custo gerado pelo hardware
grande e, por muitas vezes subutilizado desta aproximao, o maior que qualquer
outra abordagem anteriormente discutida.
62
No trabalho aqui apresentado, foi utilizada uma ferramenta de software com o propsito
de gerar o cdigo VHDL para a integrao em hardware do processador de aplicao
especfica TCP/IP. Esta ferramenta foi desenvolvida por Srgio Ito e chama-se
SASHIMI [ITO 2000]. Esta ferramenta foi escolhida devido sua facilidade de
aplicao ao ambiente aqui proposto, ou seja, a partir do cdigo gerado em um
computador utilizando a linguagem de programao C, foi simples a traduo para o
Java, que serve de fonte de entrada para o SASHIMI. Em adio a isto, a ferramenta
gera o hardware descrito em VHDL de um processador de aplicao especfica,
conforme a necessidade da aplicao fim. Alm disto, o software aplicativo que
executar no processador gerado anteriormente, tambm fornecido pela ferramenta em
questo.
Com todas as facilidades apresentadas, o SASHIMI tornou-se uma soluo bastante
atraente visando a gerao do hardware pretendido por este trabalho. Caso se leve em
considerao os esforos empregados por qualquer outro meio de desenvolvimento de
hardware e software dedicado a este fim, fica flagrante a aplicabilidade imediata desta
ferramenta, bem como a velocidade e simplicidade no fornecimento de resultados finais.
3.2 A Ferramenta SASHIMI

O primeiro estgio do trabalho foi o desenvolvimento da pilha de protocolos formadores
do TCP/IP com o auxlio da linguagem C, e do hardware do PC AT. O passo seguinte
foi a simplificao do cdigo em C, resultante de uma abordagem j funcional e
depurada no ambiente de rede Ethernet para um programa, ainda em C, mas com um
conjunto de instrues restrito quelas que a ferramenta SASHIMI implementa sem
restries. Por exemplo, o Java utilizado pelo SASHIMI no suporta estruturas de dados
da forma como so implementadas no C atravs do comando struct, bem como
operaes com ponto flutuante.
Esta etapa foi orientada no sentido de remover todas as instrues, que de uma forma ou
outra, viessem a impossibilitar a utilizao da ferramenta em questo. Outro aspecto
neste sentido foi a eliminao de todas as funes de bibliotecas externas fornecidas
pela linguagem C disponveis atravs do comando include, e a sua conseqente
codificao diretamente no corpo do programa principal.
A partir deste ponto, a traduo do cdigo em C para o Java compatvel com o
SASHIMI foi simples, praticamente direta, uma vez que as linguagens em questo so
muito semelhantes do ponto de vista sinttico.
Com a utilizao da ferramenta SASHIMI, tomando por base o programa Java como
entrada, foi gerada uma descrio VHDL de um processador especfico para a
aplicao, que apresenta ao usurio um conjunto reduzido de instrues completamente
voltadas para a aplicao fim. Este processador gerado em um FPGA [ALT 2001a]
apresenta algumas caractersticas conforme discutido a seguir.
A arquitetura composta de trs unidades distintas com as funes de seqenciamento
do fluxo de programa, gerenciamento da pilha e clculo lgico e aritmtico sobre a
pilha. Apresenta uma arquitetura do tipo de pilha com barramentos distintos para
memria de programa e memria de dados. Possui ainda portas de entrada e sada, bem
63
como um temporizador e dois nveis de interrupo. A figura 3.1 ilustra a arquitetura
utilizada no microcontrolador descrito pela ferramenta SASHIMI.
MUX
PC
RAM
IMM
MUX
Data Bus
MAR
Const
+/SP
FRM
MUX
Output
Ports
Data Mem Address Bus
Input
Ports
Intruction Bus
ROM
Prg Mem Address Bus
MUX
VAR
A
ALU
Timer
Interrupt
Handler
IR
Control
FIGURA 3.1 Arquitetura do microcontrolador FemtoJava.
As instrues geradas pela ferramenta SASHIMI so um subconjunto das instrues

disponveis em uma mquina virtual Java normal, conforme ilustra a tabela 3.1. Das 68
instrues implementadas originalmente no processador Java, somente as realmente
necessrias aplicao fim sero disponibilizadas pelo hardware para serem utilizadas
pelo software aplicativo, tambm fornecido pela ferramenta.
64
Ao ser compilado o cdigo Java ser gerado um arquivo com bytecodes Java que ter a
extenso .class. A partir deste arquivo feita uma anlise dos bytecodes realmente
utilizados pela aplicao, e a partir desta definio do conjunto de instrues gerado o
processador especfico para esta aplicao fim.
TABELA 3.1 Conjunto de instrues implementadas no SASHIMI

Tipos de Instruo
Mnemnicos
Lgica Aritmtica
iadd, isub, imul, ineg, ishr, ishl, iushr, iand, ior, ixor
Controle de Fluxo
Operaes de Pilha
Load/Store
Array
Estendido
Outras
goto, ifeq, ifne, iflt, ifge, ifgt, ifle, if_icmpeq, if_icmpne, if_icmplt, if_icmpge, if_icmpgt, if_icmple,
return, invokestatic
iconst_m1, iconst_0, iconst_1, iconst_2, iconst_3, iconst_4, iconst_5, bipush, pop, pop2, dup,
dup_x1, dup_x2, dup2, dup2_x1, swap
Iload, iload_0, iload_1, iload_2, iload_3, istore, istore_0, istore_1, istore_2, istore_3
Iaload, baload, caload, saload, iastore, bastore, castore, sastore, arraylength
load_idx, store_idx, sleep
nop, iinc, getstatic, putstatic
3.3 A Implementao
O cdigo implementado em linguagem C foi testado em um ambiente de rede de
computadores com PCs, apresentando resultados positivos do ponto de vista de
conectividade e resposta. O ambiente utilizado foi o apresentado na figura 3.2.
Internet
Rede Local de
Computadores
Servidor
Sob Teste
Cliente
(Browser)
FIGURA 3.2 Ambiente de teste.
Neste ambiente foram depurados os problemas de conexo entre hospedeiros, conforme

prev a padronizao da pilha de protocolos TCP/IP.
Os protocolos foram sendo desenvolvidos, aplicados e depurados um a um de acordo
com sua posio relativa na pilha, iniciando pelo protocolo de nvel de enlace de dados,
o IEEE 802.2. Embora este protocolo esteja diretamente integrado no hardware do
controlador Ethernet, dispensando a sua codificao pelo usurio, existem outras tarefas
que devem ser executadas pelo cdigo desenvolvido, visando ativar o controlador, e
aps sua correta ativao, manter o fluxo de pacotes nos dois sentidos da rede.
65
Aps a ativao do controlador Ethernet, o primeiro protocolo codificado foi o ARP,
responsvel pelo descobrimento na rede dos endereos de hardware de um dado
hospedeiro. A seguir o protocolo de nvel de rede foi codificado, o IP, visto que sobre
este nvel se estabelece toda a troca de informao entre hospedeiros, na forma de
datagramas.
Com a infra-estrutura de troca de dados funcional, foi codificado de forma simplificada
o protocolo ICMP, responsvel pelo utilitrio de descoberta de hospedeiros na rede
PING. Este utilitrio tambm utilizado para a depurao de problemas de
conectividade, sendo bastante til durante todo o processo de desenvolvimento e testes
deste trabalho.
Ainda sobre a infra-estrutura definida pelo protocolo IP, foi elaborado o protocolo TCP,
responsvel por toda a confiabilidade na troca de dados entre aplicaes. Sobre o TCP
foi elaborado um protocolo bastante simples, no nvel de aplicao, baseado no HTTP,
que tem por objetivo retornar ao cliente uma pequena pgina HTML.
Com toda a pilha de protocolos funcional, pde ser medido o tempo de resposta do
sistema a uma requisio do cliente, que de forma esquemtica, pode ser observada na
figura 3.3 a seguir.
Cliente
Servidor
Solicitao (ARP)
Resposta (ARP)
Tempo
SIN (TCP)
SIN, ACK (TCP)
ACK (TCP)
GET (HTTP)
Pgina HTML
Reconhecimento (TCP)
FIN ou RES (TCP)
FIGURA 3.3 Troca de dados entre cliente e servidor.
O fluxo inicia com uma tentativa do cliente em resolver o endereo MAC do servidor
baseado em seu endereo IP. O protocolo utilizado neste instante o ARP, que retorna
do servidor uma resposta contendo o seu endereo de hardware.
Com o endereo MAC resolvido o cliente solicita o estabelecimento de uma conexo
TCP com o servidor, utilizando a seqncia de trs pacotes, conforme esplanado no
captulo anterior. Caso a conexo seja corretamente estabelecida entre os dois
hospedeiros, inicia-se a fase de troca de dados de aplicao, que no presente trabalho foi
escolhido o protocolo HTTP. Neste ponto o cliente envia ao servidor a requisio de
uma pgina HTML, e o servidor retorna a pgina solicitada, aguardando o recebimento
correto dos dados atravs dos esquemas previstos no TCP para deteco e correo de
erros.
66
Com a confirmao do recebimento correto dos dados enviados, o servidor
imediatamente inicia a seqncia de desconexo do protocolo TCP, liberando desta
forma recursos de para uma possvel conexo de outro cliente.
O cdigo implementado em C foi pensado de forma a ser o menor possvel, sem afetar o
desempenho ou a funcionalidade da pilha de protocolos. O processo de conexo, troca
de dados e desconexo foi medido e apresentou-se na faixa de 1 a 2 segundos. Este
tempo de resposta do sistema pode ser sobremaneira melhorado caso seja implementada
a possibilidade do servidor processar mais de um pacote de dados de forma paralela. Na
atual configurao, para cada pacote que chega ao servidor, executado seu
processamento de forma completa, elaborada uma resposta, caso seja pertinente, e
remetida ao cliente. Isto implica em que, chegando dois pacotes de dados, um em
seguida do outro, o segundo ser desprezado, enquanto o servidor processa o primeiro,
ficando a cargo do cliente reenvi-lo. Esta aproximao, embora tenha liberado valiosos
recursos de hardware e software, apresentou a desvantagem de adicionar um pequeno
atraso no fluxo de troca de informaes. Pode-se estimar que, caso fosse implementado
o processamento paralelo de pacotes, o tempo de resposta do sistema cairia para algo
em torno de 0,1 a 0,5 segundo, baseado nas observaes feitas em softwares de
depurao de redes conhecidos por sniffers.
Visando atingir o objetivo de consumir a menor rea de silcio possvel no processador
TCP/IP resultante, o cdigo gerado em C manteve-se o menor possvel. Como
comparao pode-se observar a tabela 3.2, onde mostrado o tamanho de cdigo fonte
de uma aplicao desenvolvida para ser utilizada em ambientes onde o meio de
comunicao so rdios [ACK 92] e o cdigo elaborado neste trabalho. A
implementao TCP/IP desenvolvida para ser utilizada com rdios foi escolhida como
parmetro de comparao porque foi totalmente elaborada em C, assim como o cdigo
aqui desenvolvido.
TABELA 3.2 Comparao de cdigos fonte.
Aplicao
ARP
IP
ICMP
TCP
Total
TCP/IP on Pocket Radio
9 kB
16 kB
7 kB
44 kB
76 kB
TCP/IP em C
3 kB
2 kB
2 kB
7 kB
14 kB
Nesta tabela so comparados apenas os cdigos que executam a lgica envolvida no

processo de elaborao do protocolo em questo, deixando-se de lado todas as funes e
bibliotecas acessrias. Um item importante a ser levado em considerao na
comparao entre tamanhos de cdigo que na implementao em C do processador
TCP/IP no existe o tratamento do lado cliente do sistema, conforme anteriormente
descrito, redundando em uma diminuio significativa do cdigo resultante. Como uma
mtrica simples deste fato podemos tomar o cdigo de tratamento do protocolo ARP,
por exemplo, do TCP/IP on Pocket Radio com 9kB de tamanho, que trata tanto o lado
cliente quanto servidor, em comparao com o TCP/IP codificado em C deste trabalho
com apenas 3kB, que trata somente o lado servidor.
67
TABELA 3.3 Comparao de cdigos executveis.
Aplicao
ARP
IP
ICMP
TCP
Total
TCP/IP em C
10 kB
10 kB
10 kB
12 kB
26 kB
TCP/IP em Java
0,4 kB
0,2 kB
0,2 kB
1,2 kB
2 kB
Observando a tabela 3.3 fica evidente a reduo do cdigo obtida quando da

implementao em bytecodes Java, o tamanho do cdigo que executa as funes dos
protocolos envolvidos na aplicao fim, quando desenvolvido em C obteve um tamanho
de 26 kB, quando da sua traduo para Java o mesmo cdigo reduziu para 2 kB. A
comparao no pode ser feita com muita preciso porque o compilador C introduz uma
quantidade considervel de cdigo, sem o controle do usurio, no executvel resultante,
mas mesmo assim a reduo notvel.
Com o cdigo elaborado em C pronto, foi feita a sua simplificao, com a inteno de
facilitar, mais tarde, a traduo para a linguagem Java. Foram retiradas todas as
estruturas de dados implementadas originalmente, transformando-as em vetores simples.
Todas as funes que operavam sobre inteiros de 16 bits foram simplificadas para
passar a operar sobre inteiros de 8 bits. Finalmente, algumas funes disponveis nas
bibliotecas do C foram codificadas diretamente sobre o corpo principal do programa.
Partindo do cdigo C simplificado, foi iniciada a traduo para o Java, linguagem que
serviu de entrada para a ferramenta SASHIMI. Esta traduo foi praticamente direta,
visto que ambas linguagens so bastante semelhantes do ponto de vista sinttico. Os
cuidados que foram tomados durante esta fase foram, principalmente, devido s
diferentes caractersticas dos hardwares utilizados, ou seja o PC e o microcontrolador de
aplicao especfica.
O sistema de interrupes do PC e o sistema de interrupes do microcontrolador
possuem caractersticas prprias, e foram tratados de forma particular, evitando a
traduo direta. Outro aspecto diferenciado a forma de acesso ao barramento ISA do
controlador Ethernet, que devido a particularidades dos dois sistemas, teve formas de
codificao bastante diferenciadas.
A figura 3.4 ilustra o fluxo de aes executadas com o fim de gerar a descrio VHDL
do microcontrolador de aplicao especfica, utilizando-se a ferramenta SASHIMI, bem
como o programa de simulao e testes fornecido pela Altera chamado Max + Plus II
[ALT 2001].
68
Cdigo em Linguagem C
Cdigo em Linguagem Java
Compliao (JVM)
Arquivo .CLASS
Ferramenta SASHIMI
Descrio VHDL e Software aplicativo
Simulao e Sntese MAX + PLUS II
Hardware (FPGA)
FIGURA 3.4 Fluxo de sntese do microcontrolador TCP/IP
Aps a traduo para o Java do programa fonte, foi executada sua compilao para uma
Mquina Virtual Java, que gerou um arquivo com a extenso .class. Com base neste
arquivo a ferramenta SASHIMI produz a descrio VHDL do hardware do
microcontrolador de aplicao especfica, implementando no seu decodificador de
instrues apenas as instrues necessrias para o programa aplicativo que ser
executado por este sistema. A ferramenta produz tambm o cdigo do programa
aplicativo que dever ser armazenado na memria do microcontrolador.
O cdigo VHDL serviu de entrada para a segunda ferramenta utilizada no processo de
gerao do microcontrolador, Max + Plus II que executa a simulao e sntese do
hardware. O resultado desta sntese pode ser observado na tabela 3.3.
TABELA 3.4 Resultados da sntese do hardware

Aplicao
# Cl. lgicas
% FPGA
Freq.
(MHz)
# Intrues
FemtoJava
1979
85
3,93
68
Proc. TCP/IP
1764
61
8,71
42
Famlia: Flex 10k (Altera) - Dispositivo: EPF10K50VRC240-1
69
Para efeito de comparao, est sendo mostrada a ocupao do FPGA que integra o
microcontrolador com todas as 68 instrues disponibilizadas, chamado de Femto Java
[ITO 2001] e a seguir o mesmo microcontrolador com apenas as instrues necessrias
aplicao TCP/IP. Nota-se a pequena reduo no nmero de clulas lgicas ocupadas
no FPGA utilizado para a sntese. Isto se verifica porque o decodificador de instrues
do processador TCP/IP possui apenas 42 instrues diferentes frente s 68 do
microcontrolador Femto Java.
Outro aspecto, no menos importante, da implementao a velocidade do circuito,
denotada pela sua freqncia de relgio. Nota-se que o processador TCP/IP pode
processar a praticamente o dobro da velocidade do microcontrolador Femto Java
original. Esta comparao pode ser feita diretamente, porque o hardware componente
dos dois controladores so basicamente idnticos, diferindo apenas na quantidade de
instrues disponibilizadas ao software aplicativo.
70
4 Concluso
A troca de dados entre equipamentos de controle e proteo eltrica, empregados em

subestaes de energia eltrica, apresenta muitas opes do ponto de vista dos meios
fsicos de conexo em rede, bem como de protocolos de comunicao. Embora alguns
padres internacionais sejam publicados e de alguma forma aceitos, o fato que, do
ponto de vista prtico, muito pouca padronizao encontrada nos diversos
equipamentos ofertados no mercado.
Com a inteno de apresentar uma soluo de padronizao para este ambiente
especfico de comunicao de dados, este trabalho implementou uma soluo de
conexo via rede de equipamentos que necessitem de uma interface de comunicao,
com a inteno de troca de dados de forma local, com redes locais, ou remota, atravs
do emprego de redes de longo alcance.
O ponto central do trabalho foi o desenvolvimento de uma pea de hardware que, uma
vez conectada no equipamento gerador de dados, facilite a conexo e o estabelecimento
de uma sesso de troca de dados. Para atingir tal simplicidade de conexo, necessria
a utilizao de padres muito bem aceitos e difundidos pelo mercado mundial de
sistemas de troca de informao. Um padro bastante aceito para protocolo de
comunicao de dados o TCP/IP, que foi utilizado para este desenvolvimento.
A pilha de protocolos TCP/IP apresenta uma gama de protocolos com fins especficos,
que devem ser implementados visando compatibilidade com os sistemas existentes.
Mas, por outro lado, embora a quantidade de protocolos da pilha seja bastante extensa,
nem todos necessitam ser implementados, simplificando de forma acentuada a
implementao. Mesmo os protocolos que devam ser implementados, visando o correto
funcionamento da comunicao de dados, podem, obedecendo alguns critrios, ser
simplificados. Desta forma conseguiu-se a implementao de uma pilha de protocolos,
supostamente extensa, de uma forma bastante simples.
A inteno principal da simplicidade da pilha de protocolos foi a sua integrao em uma
pea de hardware, chamada processador TCP/IP, que possui a limitao do tamanho
mximo da rea de silcio a ser utilizada. Outro aspecto, no menos importante desta
simplicidade, o custo total do processador, que se implementado de forma completa,
poderia se tornar proibitivo, inviabilizando sua aplicao.
Com as observaes feitas durante o desenvolvimento do trabalho prtico, ficou clara a
possibilidade de execuo de um sistema dedicado ao processamento da pilha de
protocolos TCP/IP baseado totalmente em hardware. Desta forma, este sistema
monoltico libera o ambiente de gerao e de consumo de dados para a execuo de
outras tarefas, que no o processamento de datagramas ou pacotes provenientes da rede
local.
71
O processador TCP/IP em conjunto com o controlador Ethernet so peas de custo
bastante acessvel, baseado principalmente na sua simplicidade. Possuem uma pequena
rea total, simplificando sua portabilidade, em ambientes onde o tamanho e peso sejam
decisivos. Apresentam excelentes caractersticas de conectividade, baseado no nvel
fsico (Ethernet) e a pilha de protocolos utilizado para a troca de dados. Com todas as
caractersticas aqui descritas o trabalho atingiu os objetivos inicialmente propostos,
tornando vivel a sua aplicao no ambiente de controle a que se destina, bem como em
outros ambientes onde necessidades semelhantes de troca de informaes via rede se
apresentem.
4.1 Desenvolvimentos Futuros

Outras abordagens do processador TCP/IP podem ser elaboradas visando aumentar sua
simplicidade, diminuir seu custo e tamanho, bem como facilitar sua aplicabilidade.
Um exemplo neste sentido a utilizao de um microcontrolador comercial acessando
diretamente o controlador de rede Ethernet, que apresentar algumas vantagens do
ponto de vista de custo final e de ambiente desenvolvimento, visto que estes
microcontroladores so muito difundidos, baratos e apresentam muitas ferramentas para
desenvolvimento. No aspecto do desempenho reside a dvida quanto viabilidade de
aplicao. Entretanto, de uma forma geral, os microcontroladores atuais esto
apresentando caractersticas de processamento cada vez mais velozes, o que pode
viabilizar este tipo de desenvolvimento.
Um aspecto negativo desta abordagem que muito pouco, seno to somente a lgica
empregada, poder ser aproveitada do trabalho aqui elaborado, visando simplificar o
desenvolvimento do programa aplicativo do microcontrolador. Isto deve-se
principalmente, devido s diferenas muito acentuadas nos hardwares propostos, ou
seja, o controlador TCP/IP sintetizado em hardware, e o microprocessador interno ao
microcontrolador empregado.
Outro desenvolvimento a ser elaborado , de forma sistemtica e bem fundamentada, a
eliminao das simplificaes da pilha de protocolos utilizados no sistema aqui
proposto. Estas simplificaes so necessrias atualmente visando principalmente a
diminuio da rea de silcio utilizada durante a integrao em hardware do processador
TCP/IP. Mas estas simplificaes, de uma forma ou outra, afetam o desempenho geral
do sistema, deixando-o limitado quanto s suas funes de conectividade em rede. Esta
elaborao ser muito crtica, tendo em vista a sua complexidade, ou seja, qual das
simplificaes so realmente elegveis como necessrias para o perfeito funcionamento
do sistema como um todo. At que ponto devem ser implementadas, completas como
prevem os padres, ou apenas as funes mais freqentemente utilizadas? Deve-se ter
em mente que a rea de silcio ocupada pelo processador resultante deve ser mantida a
menor possvel.
Sob o ponto de vista de conectividade em rede, o padro fsico adotado neste trabalho
possui ampla gama de aplicao na maioria dos ambientes em que o protocolo TCP/IP
seja utilizado. Mas uma alterao, no sentido de retirar o controlador Ethernet e
acrescentar no seu lugar um modem (UART), visando a conexo via linha de
comunicao de dados, privada ou dedicada, dar uma outra dimenso ao aspecto da
72
interligao em redes de longa distncia. Esta abordagem implicar no acrscimo de um
protocolo especfico para o nvel de enlace de dados, que na pilha TCP/IP conhecido
por PPP (Point to Point Protocol), e a conseqente retirada do protocolo de enlace
Ethernet. O protocolo deste nvel utilizado pelo controlador Ethernet est integrado em
hardware no prprio controlador, liberando o processador TCP/IP desta tarefa. Por outro
lado, no caso do protocolo PPP, a tarefa de controlar o nvel de enlace ficar a cargo do
processador TCP/IP, adicionando mais um nvel na sua pilha de protocolos, exigindo
assim, mais recursos de hardware e rea de silcio, cobrando seu custo no desempenho
geral do sistema. Considerando-se que as velocidades de transmisso de dados
utilizadas pelos modems so, de maneira geral, bastante inferiores s velocidades
apresentadas por uma rede Ethernet, pode se tornar vivel este tipo de aproximao.
73
Bibliografia
[ACK 92]
ACKERMANN, John R. Getting Started with TCP/IP on Pocket Radio.

1992.
Disponvel
em:
<http://sr2tcp.ampr.torun.pl/packet/intro/index.html>. Acesso em: 06 fev.
2002.
[ALT 2001] ALTERA. MAX+PLUS II Software Overview. 2001. Disponvel em:

<http://www.altera.com/>. Acesso em: 06 dez. 2001.
[ALT 2001a]ALTERA. FLEX 10K Embedded Programmable Logic Family Data
Sheet. V 4.1. 2001. Disponvel em: <http://www.altera.com/>. Acesso em:
07 dez. 2001.
[BEC 2000] BECK IPC GMBH. Hardware Manual: @CHIP SC12. 2000. Disponvel
em: <http://www.bcl-online.de/>. Acesso em: 25 out. 2001.
[COM 98]
COMMER, Douglas E. Interligao em Rede com TCP/IP. Rio de

Janeiro: Campus, 1998. 670p.
[COM 99]
COMMER, Douglas E.; STEVENS, David L. Interligao em Rede com

TCP/IP. Rio de Janeiro: Campus, 1999. v.2.
[DAV 97]
DAVICOM SEMICONDUCTOR INC. DM9008 ISA/Plug and Play

Super
Ethernet
Controler.
1997.
Disponvel
em:
<http://davicom.com.tw>. Acesso em: 20 fev. 2001.
[GEN 2001] GENERAL ELECTRIC. T60 Transformer Management Relay. 2001.

Disponvel em: <http://www.geindustrial.com/industrialsystems/pm/>.
Acesso em: 24 out. 2001.
[IEE 96]
INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS.

802.3 CSMA/CD Access Method. [S. l., 1996]. 1268p.
[INT 95]
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION.
Telecontrol Equipament and Systems Part 5: Transmission Protocols
Section 101: Companion Standart for Basic telecontrol Tasks. Genebra,
1995. 181p.
[ISO 94]
INTERNATIONAL ORGANIZATION FOR STANDARTIZATION /

INTERNATIONAL ELECTROTECHNICAL COMMISSION. Open
Systems Interconnection Basic Reference Model: The Basic Model,
ISO/IEC 7498-1. [S.l.], 1994. 59p.
[ITO 2000] ITO, Srgio Akira. Projeto de Aplicaes Especficas com

Microcontroladores Java Dedicados. 2000. Dissertao (Mestrado em
Cincia da Computao) Instituto de Informtica, Universidade Federal
do Rio Grande do Sul, Porto Alegre.
74
[ITO 2001] ITO, Srgio Akira; JACOBI, Ricardo Pezzuol. Making Java Work for
Microcontroller Applications. IEEE, 2001. 12p.
[JAM 98] JAMMEL, Arhtar; STUEMPFLE, Matthias; JIANG, Daniel; FUCHS, Axel.
Web on Wheels: Toward Internet- Enabled Cars. Computer, Piscataway,
v.31, n.1, p. 69-76, Jan. 1998.
[KER 86] KERNIGHAN, Brian W.; RITCHIE, Dennis M. C a Linguagem de
Programao. Rio de Janeiro: Campus, 1986. 208p.
[KRE 97]
KREUTZ, Mrcio Eduardo. Gerao de Processador para Aplicao

Especfica. 1997. Dissertao (Mestrado em Cincia da Computao)
Instituto de Informtica, Universidade Federal do Rio Grande do Sul,
Porto Alegre.
[LIG 00] LIGHTNER ENGINEERING. How to Build a Pico Web Project. Version
2.00. 2000. Disponvel em: <http://www.picoweb.net/>. Acesso em: 20 fev.
2001.
[LOE 99] LOEWEN, Myron. AN724 Using PICMicro MCUs to connect to Internet
via PPP. 1999. Disponvel em: <http://www.microchip.com/>. Acesso em:
20 fev. 2001.
[MOD 96] MODICON INC. Modicon Modbus Protocol Reference Guide. 1996.
Disponvel
em:
<http://www.modicon.com/techpubs/TechPubNew/>.
Acesso em 19 nov. 2001.
[MUR 98] MURHAMMER, Martin W. et al. TCP/IP Tutorial and Technical
Overview. 1998. Disponvel em: <http://redbooks.ibm.com>. Acesso em:
10 dez. 2001.
[NAT 95] NATIONAL SEMICONDUCTOR CORPORATION. DP83902A ST-NIC.
Serial Network Inteface Controller for Twisted Pair. 1995. Disponvel
em: <http://national.com>. Acesso em: 10 abr. 2000.
[PLU 82] PLUMMER, D.C. Ethernet Address Resolution Protocol: Or converting
network protocol addresses to 48.bit Ethernet address for transmission on
Ethernet
hardware,
RFC
826.
1982.
Disponvel
em:
<http://sunsite.auc.dk/RFC/>. Acesso em: 28 fev. 2000.
[POS 81] POSTEL, J. Internet Protocol, RFC 791. 1981. Disponvel em:
[POS 81a] POSTEL, J. Internet Control Message Protocol, RFC 792. 1981.
Disponvel em: <http://sunsite.auc.dk/RFC/>. Acesso em: 28 fev. 2000.
[POS 81b] POSTEL, J. Transmission Control Protocol. 1981. Disponvel em:
[PRE 99] PREDKO, Myke. PC Ph. D. Inside PC Interfacing. New York: McGrawHill, 1999. 954p. p. 36 - 40.
75
[PRO 99] PROFIBUS NUTZERORGANISATION. Profibus Technical Description.
1999. Disponvel em: <http://www.profibus.com/downloads.html>. Acesso
em: 18 abr. 2002.
[REA 95] REALTEK SEMI-CONDUCTOR CO. RTL8019 Realtek Full-Duplex
Ethernet Controller with Plug and Play Function. 1995. Disponvel em:
<http://www.realtek.com.tw/>. Acesso em: 20 fev. 2001.
[SCE 2000] SCENIX SEMICONDUCTOR INC. AN35 SX-Stack: Internet
Protocols
Implementation.
2000.
Disponvel
em:
<http://www.scenix.com/>. Acesso em: 20 fev. 2001.
[SCH 97] SCHILDT, Herbert. Borland C++: Completo e Total. So Paulo: Makron
Books do Brasil, 1997. 1114p.
[SEI 2001] SEIKO INSTRUMENTS INC. Hardware Specification S7600A TCP/IP
Protocol Network LSI. 2001. Disponvel em: <http://www.seiko-usaecd.com/>. Acesso em: 20 fev. 2001.
[SHA 95] SHANLEY, Tom; ANDERSON, Don. ISA System Architecture. Reading:
Addison Wesley Longman, 2000. 517p.
[SPU 2002] SPURGEON, Charles. Quick Reference Guide to 10 Mbps Ethernet.
2002. Dispovel em: <http://ethermanage.com/ethernet>. Acesso em: 17 abr.
2002.
[TAN 97]
TANENBAUM, Andrew. Redes de Computadores. Rio de Janeiro:

Campus, 1997. 990p. p.50 75.
[VAR 98] VARHOL, Peter. Designing Communications for Web Devices. Computer
Design, Northbrook, v.37, n.9, p. 49-57, Sept. 1998.

Implementação Do Protocolo TCP/IP para Sistemas de Intrumentação

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Implementação Do Protocolo TCP/IP para Sistemas de Intrumentação

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDADE FERDERAL DO RIO GRANDE DO SUL

Implementao do Protocolo TCP/IP

Trabalho de concluso submetido avaliao,

Prof. Luigi Carro

Porto Alegre, abril de 2002.

CIP CATALOGAO NA PUBLICAO

Ribeiro, Roberto Schnhofen

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

2 O TCP/IP Implementado em C ....................................................................... 21

3 A Gerao de um ASIP ...................................................................................... 60

Anexo programa fonte em C (em disquete)

application programming interface

address resolution protocol

application specific instruction set processor

basic input output system

Companhia Estadual de Energia Eltrica

ciclic redundant check

carrier sense multiple access / collision detection

direct memory access

disc operating system

digital signal processor

electricaly erasable programmable read only memory

first in first out

field programmable gate array

file transfer protocol

hiper text markup language

hiper text transfer protocol

internet control message protocol

International Electrotechnical Comission

Institute of Electrical and Electronics Engeneers

International Organization for Standartization

Industry Standard Architecture

local area network

least significant byte

media access control

most significant byte

maximum transfer unit

open systems interconnection

packet internet groper

post office protocol

point to point protocol

random access memory

reverse address resolution protocol

reduced instruction set computing

request for comments

system as software and hardware in microcontrolers

start of frame delimiter

simple mail transfer protocol

transmission control protocol

universal assincronous receiver transmiter

user datagram protocol

VHSIC hardware description language

wide area network

Palavras Chave: TCP/IP, FPGA, SASHIMI, ASIP.

TITLE: TCP/IP PROTOCOL IMPLEMENTATION TO INSTRUMENTATION

Keywords: TCP/IP, FPGA, SASHIMI, ASIP.

A necessidade de comunicao est pressionando a pesquisa, cada vez mais, a elaborar

FIGURA 1.1 Sistema de comunicao com TCP/IP.

Uma aplicao do sistema a medio, superviso e controle do sistema de potncia

1.1 O Estgio Atual da Pesquisa Mundial

1.2 O Ambiente de Aplicao

FIGURA 1.2 Protocolos do centro de operao.

Neste ambiente com tantas possibilidades de protocolos de comunicao de dados, o