DANILO LOPES LUVIZOTO

ESTUDO DE IMPLEMENTAES DE
PILHAS TCP/IP PARA
MICROCONTROLADORES






Trabalho de Concluso de Curso
apresentado Escola de Engenharia de
So Carlos, da Universidade de So Paulo


Curso de Engenharia Eltrica com nfase
em Eletrnica



ORIENTADOR: Prof. Dr. Evandro Lus Linhari Rodrigues






So Carlos
2010

2



3

Dedicatria
Dedico este trabalho aos meus pais que tanto lutaram para eu poder ser o que
sou e pelo amor que sempre tiveram por mim. Tambm a minha querida namorada
que me apoiou em todos os momentos de minha graduao. Alm, claro, de todos
os amigos, que juntos batalhamos e vencemos mais uma vez.



4



5

Agradecimentos
Agradeo primeiramente a Deus por me iluminar nos caminhos mais difceis,
ao Professor Evandro pela orientao e incentivo deste trabalho e a todos outros
professores e colegas que me ajudaram em tudo que sei hoje.



6



7

Resumo
Este trabalho apresenta um comparativo entre duas implementaes de pilhas
TCP/IP para sistemas embarcados baseados em microcontrolador. O trabalho foi
desenvolvido utilizando um microcontrolador MSP430 da Texas Instruments,
embarcado em uma placa de desenvolvimento da Olimex. O trabalho consistiu em
duas tarefas: a primeira foi o estudo de cada pilha e a segunda foi uma comparao e
desenvolver uma aplicao. O objetivo foi enfatizar algumas das principais diferenas
entre as pilhas sugerindo algumas aplicaes.

Palavras chave: Sistemas Embarcados, Protocolo TCP/IP, Comunicao Internet,
MSP430



8



9

Abstract
This paper shows a comparison between two TCP / IP stacks for embedded
systems implemented based on microcontrollers. The study was conducted using a
MSP430 microcontroller from Texas Instruments, included in the development kit from
Olimex. The work consisted of two tasks: the first one was the study of each stack and
second was a comparison and develop an application. The objective was to emphasize
some differences between the stacks and suggest some applications.
Keywords: Embedded systems, TCP/IP protocol, Internet communication, MSP430


10



11

Sumrio
Dedicatria ................................................................................................................... 3
Agradecimentos ............................................................................................................ 5
Resumo...... .................................................................................................................. 7
Abstract .............................................................................................................. 9
Lista de Figuras .......................................................................................................... 13
Lista de Tabelas ......................................................................................................... 15
Lista de Abreviaturas .................................................................................................. 16
1. Introduo ........................................................................................................ 17
1.1 Motivao ..................................................................................................... 17
1.2 Objetivos ...................................................................................................... 18
1.3 Organizao do texto .................................................................................... 18
2. Introduo Terica ........................................................................................... 19
2.1 Redes de computadores ............................................................................... 19
2.2 Protocolos e hierarquias ............................................................................... 21
2.3 Protocolo TCP/IP .......................................................................................... 22
3. Materiais e mtodos ......................................................................................... 31
3.1 Kit EasyWeb 2 .............................................................................................. 31
3.2 MSP 430 ....................................................................................................... 32
3.3 CS8900 ........................................................................................................ 35
3.4 Comparao entre as pilhas TCP/IP ............................................................. 37

12

3.5 Pilha de Andreas Dannenberg ...................................................................... 38
3.6 Pilha uIP (Adam Dunkels) ............................................................................. 41
4. Resultado e discusso ..................................................................................... 45
5. Concluso ........................................................................................................ 52
Referencia Bibliogrfica .............................................................................................. 53


13

Lista de Figuras
Figura 1 - Calculadora (Model K) [1] ........................................................................... 20
Figura 2 - Camadas, Nveis e Protocolos [1] ............................................................... 22
Figura 3 - Camadas Protocolo TCP/IP ........................................................................ 23
Figura 4 - Modelo OSI - TCP/IP .................................................................................. 24
Figura 5 - Cabealho TCP [2] ..................................................................................... 25
Figura 6 - Estabelecimento de conexo TCP .............................................................. 26
Figura 7 - Transmisso de dados TCP ....................................................................... 27
Figura 8 - Finalizao da conexo TCP ...................................................................... 27
Figura 9 - Cabealho IP [2] ......................................................................................... 28
Figura 10 - Encapsulamento TCP/IP ........................................................................... 29
Figura 11 - Fragmentao de pacotes IP .................................................................... 30
Figura 12 - Kit Olimex EasyWeb 2 [3] ......................................................................... 32
Figura 13 - Esquema Pinos MSP430F149 [4] ............................................................. 34
Figura 14 - Arquitetura interna do MSP430 [4] ............................................................ 35
Figura 15 - Diagrama do controlador CS8900 [6] ........................................................ 36
Figura 16 - Fluxograma da funo DoNetworkStuff() .................................................. 40
Figura 17 - Fluxograma bsico do protocolo uIP ......................................................... 44
Figura 18 - Resposta da pilha de Andreas Dannenberg ao comando ping .................. 49
Figura 19 - Resposta da pilha uIP ao comando ping ................................................... 49
Figura 20 - Teste mltiplas conexes da pilha de Andreas Dannenberg ..................... 50

14

Figura 21 - Teste mltiplas conexes da pilha uIP ...................................................... 50


15

Lista de Tabelas
Tabela 1 - Tamanho de pacotes ................................................................................. 30
Tabela 2 - Caractersticas Eltricas do MSP430 [4] .................................................... 35
Tabela 3 - Comparao entre as duas pilhas .............................................................. 47
Tabela 4 - Tamanho de cdigo das pilhas .................................................................. 47
Tabela 5 - Uso de memria RAM ................................................................................ 48



16

Lista de Abreviaturas
IP - Internet Protocol
RISC - Reduced Instruction Set Computer
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
SMTP - Simple Mail Transfer Protocol
ICMP - Internet Control Message Protocol
HTTP - HyperText Transfer Protocol
ARPA - Advanced Research Projects Agency
ACK - Acknowledgement
SACK - Selective ACK
MTU - Maximum Transfer Unit
FDDI - Fiber Distributed Data Interface
CRC - Cyclical Redundancy Check
QFP - Quad Flat Pack
LAN - Local Area Network
IETF - Internet Engineering Task Force
NAS - Network Attachment Storage
FTP - File Transfer Protocol


17

1. Introduo
Sistema embarcado um sistema microprocessado no qual o hardware
dedicado ao sistema que ele controla, diferente de computadores que executam vrias
tarefas ao mesmo tempo com propsitos diferentes. Um sistema embarcado realiza
um conjunto de tarefas predefinidas, geralmente com requisitos especficos. J que o
sistema dedicado a tarefas especficas, pode-se aperfeioar o projeto reduzindo
tamanho, recursos computacionais e custo do produto de acordo com a aplicao.
Diante diss,o esto cada vez mais presentes em nosso cotidiano, controlando,
monitorando e comunicando e entre diversas outras operaes encontramos sistemas
embarcados. O surgimento de novas aplicaes impulsionado pelo crescimento do
mercado e um melhor conhecimento das necessidades.
E nesse contexto tm cada vez mais necessidades de comunicao, devido a
controle, monitorao e segurana. Com isso a internet uma alternativa vivel e
muitas vezes de custo reduzido. neste contexto que este trabalho se encaixa,
fazendo a integrao da aplicao com o equipamento, onde cada equipamento pode
ser monitorado com sensores. E com a utilizao da internet pode-se control-lo e
monitor-lo remotamente, tendo como nico pr-requisito uma conexo ativa com a
internet.
As duas pilhas TCP/IP que iremos estudar so duas implementaes reduzidas
da pilha que implementada para computadores. A maior restrio de ambas
implementaes o hardware com menor capacidade de processamento e menor
tamanho de memria RAM. Mas, mesmo diante das limitaes, as duas pilhas tm
que ser totalmente compatveis com as pilhas implementadas para computadores, pois
devero se comunicar sem perdas.
1.1 Motivao
A motivao deste trabalho partiu das limitaes encontradas na pilha TCP/IP
de Andreas Dannenberg diante de vrias aplicaes. Assim, sabendo da existncia da
pilha de Adam Dunkels, aqui referida somente como uIP, teve-se a oportunidade de
verificar as diferenas e conseqentemente uma melhora nas possveis aplicaes
com o kit de desenvolvimento Olimex EasyWeb2.


18

1.2 Objetivos
O objetivo deste trabalho comparar de forma qualitativa duas pilhas de
protocolos TCP/IP implementadas para sistemas embarcados com microcontroladores
MSP430 da Texas Instruments, e por fim exemplificar com uma aplicao que
demonstre as diferenas entre as duas implementaes.

1.3 Organizao do texto
Este trabalho est dividido em seis captulos, sendo que o primeiro captulo
somente uma apresentao do tema proposto e os objetivos a serem alcanados.
O segundo captulo faz uma introduo a todos os conceitos necessrios para
o entendimento, tanto do trabalho. Introduzindo conceitos de redes e protocolos, alm
contexto em que se enquadram.
No terceiro captulo, o foco do trabalho, onde so feitas as explicaes das
duas pilhas, alm dos matrias e mtodos utilizados para a comparao e logo aps
um comparativo de todas as diferenas que so importantes.
No quarto captulo foi mostrado todos os resultados obtidos atravs do estudo
das duas pilhas.
O quinto captulo conclui o trabalho, analisando os resultados e testes
realizados e tambm propes novas implementaes e solues.
E no ltimo captulo tm-se as referncias bibliogrficas que foram utilizadas
para a composio deste trabalho.


19

2. Introduo Terica
Cada um dos trs sculos anteriores foi dominado por uma nica tecnologia. O
sculo XVIII foi a poca dos grandes sistemas mecnicos que acompanharam a
Revoluo Industrial. O sculo XIX foi a era das mquinas a vapor e no sculo XX as
principais conquistas tecnolgicas deram-se no campo da aquisio, do
processamento e da distribuio de informaes [1].
Neste ltimo sculo, com a inveno do transistor teve-se a revoluo
eletrnica, o que possibilitou vrias inovaes. Com isso, os processadores puderam
evoluir tanto que quase todos os controles eletrnicos atualmente so
microprocessados. Essa evoluo foi acompanhada, nos ltimos anos, pelo
crescimento dos sistemas de comunicao e em especial pelas redes de
computadores.
2.1 Redes de computadores
Antes do advento de computadores dotados com algum tipo de sistema de
telecomunicao, a comunicao entre mquinas calculadoras e computadores
antigos era realizada por usurios atravs do carregamento de instrues entre eles.
Em 1940, George Stibitz utilizou uma mquina de teletipo
1
para enviar
instrues com um conjunto de problemas a partir de sua calculadora Model K (Figura
1) na Faculdade de Dartmouth em Nova Hampshire para a sua calculadora em Nova
Iorque e recebeu os resultados de volta pelo mesmo meio.


1
Equipamento eletromecnico de transmisso de dados

20


Figura 1 - Calculadora (Model K) [1]

Conectar sistemas de sada, como teletipos a computadores, era um interesse
na ARPA (Advanced Research Projects Agency) quando, em 1962, J. C. R. Licklider
foi contratado e desenvolveu um grupo de trabalho o qual ele chamou de a "Rede
Intergalctica", um precursor da ARPANET.
Durante a dcada de 1960, Leonard Kleinrock, Paul Baran e Donald Davies, de
maneira independente, conceituaram e desenvolveram sistemas de redes, os quais
usavam datagramas ou pacotes, que podiam ser usados em uma rede de comutao
de pacotes entre sistemas de computadores.
Em 1969, a Universidade da Califrnia em Los Angeles, SRI (em Stanford), a
Universidade da Califrnia em Santa Brbara e a Universidade de Utah foram
conectadas com o incio da rede ARPANET usando circuitos com capacidade de
transmisso de 50 kbits/s. Essa rede denominada de ARPANET era uma rede que
interligava bases militares e departamentos de pesquisa do governo americano. Ela
utilizava um backbone que passava por baixo da terra, sem ter um centro ou caminho
definido. Essa tcnica conferia ao sistema um segurana, pois no tinha um elemento
principal, que se fosse destrudo impactava no sistema.
Redes de computadores e as tecnologias necessrias para conexo e
comunicao, atravs e entre elas, continuam a comandar as indstrias de hardware
de computador, software e perifricos. Essa expanso espelhada pelo crescimento
nos nmeros e tipos de usurios de redes, desde o pesquisador at o usurio
domstico.

21

Atualmente, redes de computadores so o ncleo da comunicao moderna. O
escopo da comunicao cresceu significativamente na dcada de 1990 e essa
exploso nas comunicaes no teria sido possvel sem o avano progressivo das
redes de computadores.
As redes em si no so somente os meios fsicos de transmisso, mas um
conjunto de software e hardware que comanda e controla as conexes. Por isso as
regras das comunicaes devem ser claras para todos os elementos envolvidos em
uma conexo, com isso todos os sistemas de comunicao tm protocolos, que
gerenciam toda a comunicao, desde a inicializao at o trmino da conexo,
fazendo o gerenciamento de perdas, tempos e limites, tentando sempre maximizar a
transferncia e o uso do hardware e minimizar os problemas.
2.2 Protocolos e hierarquias
Para reduzir a complexidade do projeto, a maioria das redes organizada
como uma pilha de nveis ou camadas, colocadas umas sobre as outras. O nmero de
camadas, o nome, o contedo e a funo de cada camada diferem de uma rede para
outra. No entanto, em todas as redes o objetivo de cada camada oferecer
determinados servios s camadas superiores, isolando essas camadas dos detalhes
de implementao desses recursos. De certa forma, cada camada uma espcie de
mquina virtual, oferecendo determinados servios camada situada acima dela.
Na realidade, esse conceito familiar e utilizado em toda a cincia da
computao, na qual conhecido por nomes diferentes, como ocultao de
informaes, tipos de dados abstratos, encapsulamento de dados e programao
orientada a objetos. A idia fundamental que um determinado item de software (ou
hardware) fornece um servio a seus usurios, mas mantm ocultos os detalhes de
seu estado interno e de seus algoritmos.
A camada n de uma mquina se comunica com a camada n de outra mquina.
Coletivamente, as regras e convenes usadas nesse dilogo so conhecidas como o
protocolo da camada n. Basicamente, um protocolo um acordo entre as partes que
se comunicam, estabelecendo como se dar a comunicao. A violao do protocolo
dificultar a comunicao, se no a tornar completamente impossvel. A Figura 2
ilustra uma rede de cinco camadas. As entidades que ocupam as camadas
correspondentes em diferentes mquinas so chamadas pares (peers). Os pares

22

podem ser processos, dispositivos de hardware ou mesmo seres humanos. Em outras
palavras, so os pares que se comunicam utilizando o protocolo [1].

Figura 2 - Camadas, Nveis e Protocolos [1]

2.3 Protocolo TCP/IP
Com o sucesso da Internet, o modelo de protocolos TCP/IP se tornou o padro
internacional de comunicao. o protocolo utilizado para transferncia de web
pages, transmisses de email, transferncia de arquivos atravs da Internet. Sistemas
embarcados que possuem o protocolo implementado sero elementos importantes,
que podem se comunicar tanto via Internet quanto dentro de uma Intranet, que uma
verso privada da Internet.
O TCP/IP um conjunto de protocolos de comunicao entre computadores
em rede. Seu nome vem de dois protocolos: o TCP - Protocolo de Controle de
Transmisso e o IP - Protocolo de Interconexo. O protocolo estruturado em um
modelo de camadas, onde cada camada responsvel por algumas tarefas,
fornecendo um conjunto de servios definidos para o protocolo da camada superior.
As camadas mais altas esto logicamente mais prximas do usurio. O modelo
estruturado de acordo com a Figura 3.

23


Figura 3 - Camadas Protocolo TCP/IP
Este modelo de camadas uma idia que surgiu com o modelo OSI (Open
Systems Interconnection), que um modelo onde se tem sete camadas estruturadas
de forma semelhante ao que se tem no modelo TCP\IP. Este modelo o precursor de
quase todos os modelos de comunicao que se tem hoje. As cinco camadas do
modelo TCP/IP so relacionadas com as camadas do modelo OSI de acordo com a
Figura 4.


24


Figura 4 - Modelo OSI - TCP/IP
Os protocolos TCP\IP possuem cinco camadas, mas as pilhas implementadas
esto focadas nas camadas de transporte e de rede. Todas as outras camadas abaixo
sero associadas como dispositivos de redes e a camada acima simplesmente como
camada de aplicao.
O protocolo TCP especifica trs fases durante a conexo: primeiro o
estabelecimento da conexo, depois a transmisso e por ltimo o trmino da conexo.
O cabealho do protocolo TCP pode ser visto na Figura 5. Ele composto
basicamente da porta de origem e de destino, alm do nmero de sequncia que
identifica a posio deste pacote diante de um fluxo de pacotes, por um nmero que
confirma o recebimento do pacote e por alguns bits de controle, alm do tamanho do
cabealho. Possui tambm um campo de verificao de erros do cabealho e um
campo em que a origem determina para indicar onde est algum dado urgente dentro
do pacote. E, por ltimo, temos os dados que so basicamente o pacote do protocolo
que utilizado pela aplicao.

25


Figura 5 - Cabealho TCP [2]

O estabelecimento da ligao ocorre de forma ordenada, onde o cliente envia
um pacote em que ele pede uma conexo com o servidor. Assim que o servidor
recebe o pacote, ele devolve um pacote de confirmao (ACK - Acknowledgement)
juntamente com um pacote informando a aceitao da conexo, mas, caso o servidor
no receba o pacote, o cliente espera um tempo (Timeout) e reenvia o pacote. E, para
finalizar o processo de estabelecimento de conexo, o servidor devolve um pacote de
confirmao (ACK) conforme Figura 6.


Figura

Depois de estabelecida a conexo
dados, conforme Figura 7, em que o servidor envia os dados conforme solicitado pelo
cliente. Esse envio ocorre de forma ordenada, e assim que o cliente recebe os dados
ele devolve um pacote de confirmao contendo o nmero do pacote recebido para se
manter uma alta confiabilidade. Uma grande vantagem do TCP, que ele pode
confirmar pacotes que chegam fora da ordem previamente estabelecida atravs de um
pacote de confirmao (SACK
contm um campo de verificao de erros (
integridade do pacote recebido.
26

Figura 6 - Estabelecimento de conexo TCP
pois de estabelecida a conexo comea o processo de transferncia de
, em que o servidor envia os dados conforme solicitado pelo
cliente. Esse envio ocorre de forma ordenada, e assim que o cliente recebe os dados
confirmao contendo o nmero do pacote recebido para se
manter uma alta confiabilidade. Uma grande vantagem do TCP, que ele pode
confirmar pacotes que chegam fora da ordem previamente estabelecida atravs de um
pacote de confirmao (SACK - Selective ACK). O cabealho do protocolo TCP
contm um campo de verificao de erros (Checksum), o que permite assegurar a
integridade do pacote recebido.
comea o processo de transferncia de
, em que o servidor envia os dados conforme solicitado pelo
cliente. Esse envio ocorre de forma ordenada, e assim que o cliente recebe os dados
confirmao contendo o nmero do pacote recebido para se
manter uma alta confiabilidade. Uma grande vantagem do TCP, que ele pode
confirmar pacotes que chegam fora da ordem previamente estabelecida atravs de um
). O cabealho do protocolo TCP
), o que permite assegurar a


Figura

Para finalizar a aplicao, qualquer uma das p
finalizao, e a outra parte devolve um pacote de confirmao e logo depois manda
tambm um pacote de finalizao
devolve um pacote de confirmao.
Figura

O protocolo TCP introduz um conceito de porta, que est associado a um
servio da camada de aplicao. Assim cada conexo utiliza uma porta especfica
para o tipo de aplicao. O protocolo TCP usa o p
27

Figura 7 - Transmisso de dados TCP
Para finalizar a aplicao, qualquer uma das partes manda um pacote de
finalizao, e a outra parte devolve um pacote de confirmao e logo depois manda
tambm um pacote de finalizao conforme Figura 8. E por fim a primeira parte
devolve um pacote de confirmao.

Figura 8 - Finalizao da conexo TCP
O protocolo TCP introduz um conceito de porta, que est associado a um
servio da camada de aplicao. Assim cada conexo utiliza uma porta especfica
para o tipo de aplicao. O protocolo TCP usa o pacote IP para entrega dos
artes manda um pacote de
finalizao, e a outra parte devolve um pacote de confirmao e logo depois manda
. E por fim a primeira parte
O protocolo TCP introduz um conceito de porta, que est associado a um
servio da camada de aplicao. Assim cada conexo utiliza uma porta especfica
acote IP para entrega dos

28

datagramas rede. J o pacote IP trata os pacotes TCP como dados e no interpreta
qualquer contedo das mensagens TCP.
Representando o cabealho de um pacote IP temos a Figura 9. Neste
cabealho temos basicamente, o tamanho do cabealho, como o tamanho do pacote
inteiro. Temos tambm o tempo de vida antes que o pacote no seja mais
retransmitido, possui tambm os endereos de origem e destino, alm de um
verificador de erros do cabealho e alguns bits para controle. E ocupando a maior
parte do pacote temos a rea de dados, que onde ser transportado o pacote TCP
que vai ser transmitido.

Figura 9 - Cabealho IP [2]

O protocolo IP usado para encaminhamento de dados. O IP oferece um
servio de datagramas no confivel, ou seja, o pacote chega sem garantias, mas isso
resolvido pelo protocolo da camada de transporte, como explicado no protocolo TCP,
que faz toda a verificao de erros (Checksum). Vamos supor que tenham muitas
redes interconectadas por gateways, mas s tenham dois hosts em cada extremo da
interconexo das redes, quando um host quer enviar ao outro, ele encapsula o
datagrama e o envia ao gateway mais prximo. Uma vez que o quadro chega ao
gateway, o software de IP extrai o datagrama encapsulado, e as rotinas de


roteamento IP selecionam o prximo
levar o datagrama ao host

Figura
Um problema que as pilhas TCP/IP tm que solucionar, a fragmentao
pacotes. Por passarem por v
vezes as redes no tm capacidade de enviar pacotes IP no tamanho
foram recebidos. Com isso tem
feito em switches que interligam duas redes diferentes conforme
vai dividir os pacotes e reencap
remont-los. Na Tabela 1 temos os tamanhos de pacot
uma rede Ethernet padro, uma rede ARPANET, e uma rede FDDI (
Data Interface) que uma tecnologia de transmisso de dados que utiliza o protocolo
de transmisso Token Ring
ordem de Gigabits\s. O Token
tem que possuir o Token.
29
roteamento IP selecionam o prximo gateway que formar parte do caminho que
host destino, conforme representado na Figura
Figura 10 - Encapsulamento TCP/IP

Um problema que as pilhas TCP/IP tm que solucionar, a fragmentao
pacotes. Por passarem por vrias redes distintas, com tecnologias diferentes, muitas
vezes as redes no tm capacidade de enviar pacotes IP no tamanho original que eles
foram recebidos. Com isso tem-se uma fragmentao de pacotes, que normalmente
que interligam duas redes diferentes conforme Figura
vai dividir os pacotes e reencapsul-los, de maneira que o receptor final consiga
temos os tamanhos de pacotes em diferentes tipos de redes:
padro, uma rede ARPANET, e uma rede FDDI (Fiber Distributed
ue uma tecnologia de transmisso de dados que utiliza o protocolo
Token Ring e possui capacidade de transmisso muito elevadas, da
Token Ring funciona de forma circular, e quem quer transmitir



que formar parte do caminho que
Figura 10.

Um problema que as pilhas TCP/IP tm que solucionar, a fragmentao de
rias redes distintas, com tecnologias diferentes, muitas
original que eles
se uma fragmentao de pacotes, que normalmente
Figura 11. O switch
los, de maneira que o receptor final consiga
es em diferentes tipos de redes:
Fiber Distributed
ue uma tecnologia de transmisso de dados que utiliza o protocolo
e possui capacidade de transmisso muito elevadas, da
funciona de forma circular, e quem quer transmitir

30

Tabela 1 - Tamanho de pacotes
Tipo de rede MTU (em bytes)
Ethernet 1500
ARPANET 1000
FDDI 4470


Figura 11 - Fragmentao de pacotes IP



31

3. Materiais e mtodos

3.1 Kit EasyWeb 2
Para a realizao deste trabalho foi utilizado o kit de desenvolvimento Olimex
EasyWeb2 mostrado na Figura 12. A utilizao foi devido disponibilidade do mesmo
nos laboratrios da Engenharia Eltrica (LAB-SEL) da Escola de Engenharia de So
Carlos (EESC) da Universidade de So Paulo (USP).
O kit de desenvolvimento possui um microcontrolador da Texas Instruments, o
MSP430, juntamente com uma memria EEPROM 24LC515 de 64 Kbytes, que se
comunica com o microcontrolador pelo padro IC. O padro IC um tipo de
comunicao serial que se opera com dois canais, sendo um de dados e outro de
clock para sincronismo. O kit composto dos seguintes componentes:
MSP430F149 rodando pilha TCP/IP de Andreas Dannenberg
1

Controlador LAN CS8900 + Transformador + Conector RJ45
Trs Leds de status da LAN
Dois rels 10A/240VAC
Quatro entradas foto acopladas
Quatro chaves Push Button
Comunicao Serial RS232
Buzzer
Display LCD 16x2
Memria EEPROM 64k - 24LC515
Cristal oscilador de 8Mhz
Conector JTAG

1
Cdigo-livre a todos desde que citem a referncia.

32


Figura 12 - Kit Olimex EasyWeb 2 [3]

3.2 MSP 430
O microcontrolador utilizado no kit de desenvolvimento o MSP430F149
fabricado pela Texas Instruments, baseados em arquitetura RISC de 16 bits.
voltado para aplicaes de baixo consumo, para aplicaes embarcadas e portteis.
Possu memria de flash 60 Kbytes e 2 Kbytes de memria RAM.
Por ser de baixo consumo apresenta baixa tenso de operao, variando de
1,8 V 3,6 V. Trabalha tipicamente com uma corrente de 280 A 1 MHz e 2,2V de
Vcc. bastante econmico em modo stand-by, consumindo aproximadamente 1,6
A, podendo operar em modo de reteno de memria RAM, com apenas 0,1 A de
corrente. Para reduzir consumo de energia, o MSP430 apresenta cinco modos de
consumo de energia. Possu um tempo de wake-up de 6 s.
O MSP430 no tolerante a entradas em nvel TTL, ou seja, 5 V. Logo no
possvel que dispositivos TTL transmitam informaes diretamente ao
microcontrolador, mas o contrario possvel, pois os padres TTL aceitam o nvel de
tenso que o MSP430 suporta, ou seja, 3,6 V.

33

Possui conversor A/D de 12 bits com referncia interna, timers de 16 bits.
Possui um sistema flexvel de clocks, que pode ser mudado durante a execuo de
programas. Tem geradores de clock internos de 12 KHz, 32,768 KHz e de 16 MHz,
alm do clock externo.
Para programao tem uma lista contendo 51 instrues com trs formatos e
com sete modos de endereo. Os formatos podem ser de trs tipos: Dual-operand:
dois operandos - fonte e destino; Single-operand: apenas um operando, que pode ser
uma fonte ou um destino; Jump: instrues de salto no programa. Para programao
tem uma lista contendo 51 instrues com trs formatos e com sete modos de
endereo. Os formatos podem ser de trs tipos: Dual-operand que so dois
operandos - fonte e destino; Single-operand que tem apenas um operando, que pode
ser uma fonte ou um destino; e Jump em que possui instrues de salto no programa.
Os modos de endereamento so os seguintes: Modo imediato; Modo registrador;
Modo indexado; Modo simblico; Modo absoluto; Modo indireto; e Modo indireto com
auto incremento.
Possui comparador interno no prprio chip, no necessitando de uso de
comparadores externos. Possui cinqenta I/Os (entrada/sada), e sessenta e quatro
pinos em um chip formato QFP conforme Figura 13.
A programao pode ser realizada on-board, por comunicao serial, e possui
um mdulo JTAG para emulao. O microprocessador apresenta dois mdulos
USART, que podem ser operados como UART assncrona, ou como interface SPI
sncrona.

34


Figura 13 - Esquema Pinos MSP430F149 [4]

Temos na Figura 14 o diagrama que mostra a arquitetura interna do chip em
bloco, mostrando de forma sintetizada a forma de comunicao interna.


35

Figura 14 - Arquitetura interna do MSP430 [4]
J na Tabela 2 tem-se as caractersticas eltricas do MSP430, como tenso de
operao, consumo em determinadas freqncias, corrente de entrada e sadas
suportadas, e tambm de condies de operao.

Tabela 2 - Caractersticas Eltricas do MSP430 [4]

3.3 CS8900
CS8900 um controlador LAN Ethernet de baixo custo, para aplicaes
embarcadas. No necessita de outros controles adicionais, sendo tudo incorporado no
prprio chip. O CS8900 tem incluso RAM, transmissor e receptor (10Base-T) que
uma implementao da Ethernet que suporta transmisses taxa de 10 Mbits\s e
interface via barramento ISA para comunicao com o microcontrolador, que um
barramento paralelo de 8 bits. O esquema do diagrama interno do controlador pode
ser observado na Figura 15.

36

O controlador alm da alta integrao e pequeno tamanho oferece ampla gama
de recursos de desempenho e opes de configurao. Sua arquitetura adapta-se aos
padres de trfego da rede e dos recursos disponveis. O resultado uma maior
eficincia do sistema como um todo [5].
IEEE 802.3 Ethernet
Modo de operao Full-duplex
Portas e Filtros 10Base-T (polarizao e deteco/correo)
Retransmisso automtica quando ocorre coliso
Rejeio automtica de pacotes com erros
Suporte EEPROM com jumper
LED de link status e atividade da LAN
Stand-by e modos de baixo consumo de energia
Opera com 3 V ou 5 V
Consumo mximo em 5 V = 120 mA; e tpico em 5 V = 90 mA
100 pinos TQFP

Figura 15 - Diagrama do controlador CS8900 [6]


37

3.4 Comparao entre as pilhas TCP/IP
O foco principal deste trabalho a comparao das duas pilhas de protocolos
TCP/IP que sero discutidas a seguir. importante para compararmos as pilhas,
entendermos cada uma individualmente. Assim, neste trabalho realizada uma
descrio de cada uma das pilhas citando cada uma de suas principais funes, e a
partir desta descrio teremos o comparativo.
As implementaes das duas pilhas analisadas neste trabalho utilizam pilhas
simplificadas, pois a pilha de protocolo padro de TCP/IP requer uma grande
quantidade de memria, tanto de memria para o cdigo quanto de memria RAM
para abrigar suas variveis. Como no h grande disponibilidade de memria as duas
pilhas no abrangem toda complexidade do protocolo. Sendo assim as duas pilhas
so desenvolvidas tendo o mnimo necessrio para o protocolo funcionar, mas no
deixando de ser compatvel com todos os sistemas existentes.
A pilha completa TCP/IP consiste em inmeros protocolos, que vo desde
protocolo ARP que traduz endereo IP para endereos MAC, protocolos de aplicao,
como SMTP (Simple Mail Transfer Protocol) que utilizado para transferir texto de
email. As duas pilhas so voltadas para os protocolos TCP e IP.
Basicamente o protocolo TCP fornece um fluxo confivel de bytes para os
protocolos da camada superior. Ele divide o fluxo em segmentos de tamanhos
adequados e cada segmento enviado em seu prprio pacote IP. Os pacotes IP, so
por sua vez enviados pelo controlado de rede. Caso o destino no esteja conectado
fisicamente ao emissor, este envia o pacote a um roteador, que envia ao destino. Caso
o tamanho mximo de pacotes aceito pela outra rede seja menor do que o tamanho do
pacote enviado, o roteador fragmenta o pacote em pacotes com tamanho menor, com
isso necessrio que o receptor consiga remontar o pacote.
As pilhas so implementadas respeitando os requisitos da RFC1122. As RFCs,
so Request For Coments, que so documentos que descrevem os padres de cada
protocolo de comunicao da Internet. Qualquer pessoa pode gerar uma RFC, que vai
ser aprovada, ou no pelo IETF (Internet Engineering Task Force), e posteriormente
publicada aps reviso como uma RFC.


38

3.5 Pilha de Andreas Dannenberg
O cdigo desenvolvido por Andreas Dannenberg segue uma estrutura mais
enxuta, mas no deixando de ser eficiente. Tem-se suporte somente a aplicao de
um servidor web, suportando somente IPv4 e no possui suporte ao IPv6. O IPv6,
surgiu diante das limitaes de endereo que o IPv4 veio a apresentar. Como a
Internet quando foi criada no tinha fins comerciais, o endereo com quatro octetos
(IPv4) foi suficiente at os dias atuais, mas est com previso de esgotamento para
meados de 2011, ento est sendo implantado o endereo com oito octetos (IPv6), em
paralelo ao IPv4. Diante disso, uma falta que poder ter um impacto maior quando
todos os endereos de internet forem migrados para o IPv6.
A pilha desenvolvida com base na RFC793, e com isso totalmente
compatvel com qualquer sistema de rede com suporte a TCP/IP, algumas
funcionalidades que no so essenciais ao funcionamento da pilha TCP/IP no foram
implementadas, pois totalmente voltado pra microcontroladores de 8 bits, com baixo
consumo de RAM e de memria de programa, apesar de alguns mdulos no serem
implementados, no complexo o estudo para posterior implementaes.
Basicamente o programa comea inicializando o microcontrolador, suas portas,
alm de clocks e as comunicaes externas, como a serial. Depois se inicializa o
controlador de rede. Logo aps toda parte de inicializao concluda, entra em
funcionamento a pilha.
Em funcionamento a pilha fica esperando algum chamado de conexo vindo de
um cliente. Quando acontece algum evento, feita uma verificao para saber se
um chamado para conexo. Caso seja, a pilha entra em modo de estabelecimento de
conexo. Logo aps a conexo estabelecida comea o envio dos pacotes contendo
uma pgina web (essa pgina web foi previamente colocada na memria do
microcontrolador no momento da programao), por fim finalizando a conexo.
Algumas funes e parmetros so muito importantes para o entendimento da
pilha, pois alm do entendimento do protocolo TCP/IP, importante saber como
tratado o dado pela pilha. A seguir so descritas as principais funes que compem a
pilha elaborada por Andreas Dannenberg.


39

void TCPLowLevelInit(void)
Essa funo faz a inicializao do controlador de rede e de vrias variveis,
alm de configurar as portas e o Timer_A do MSP430. Ela deve ser chamada antes de
transmitir qualquer dado por TCP/IP.
void Init8900(void)
Configuras as portas do CS8900 - controlador de rede - que se comunica com
o microcontrolador, e faz toda configurao do controlador.
void TCPPassiveOpen(void)
Essa funo coloca o controlador no modo servidor, esperando por uma
conexo. O flag SOCK_ACTIVE muda para o estado ocupado. Antes de chamar a
funo deve-se configurar a porta atravs da varivel global TCPLocalPort. O IP do
servidor configurado nas quatro constantes, MYIP_1 a MYIP_4, no arquivo tcpip.h.
void TCPActiveOpen(void)
Com essa funo possvel se conectar a um servidor remoto. O flag
SOCK_ACTIVE muda para o estado ocupado. Antes de se utilizar a funo, o IP do
servidor remoto e as portas local e remota devem ser configuradas, respectivamente,
atravs das variveis RemoteIP, TCPLocalPort e TCPRemotePort.
void TCPClose(void)
Essa funo fecha uma conexo aberta. Se algum pacote estiver no buffer de
sada, ele ser enviado antes da conexo ser fechada. Uma nova conexo pode ser
aberta aps o uso desta funo.
void TCPReleaseRxBuffer(void)
Essa funo apaga o buffer de entrada. Deve ser utilizada aps a leitura dos
dados para que novos dados possam ser recebidos. Ela limpa o flag
SOCK_TX_BUF_RELEASED, que indica a presena de dados novos. Para se realizar
a leitura do buffer de entrada, deve-se ler a rea de memria apontada pelo ponteiro
TCP_RX_BUF. O nmero de bytes recebidos indicado pela varivel
TCPRxDataCount.

40

void TCPTranmitTxBuffer(void)
Essa funo envia dados sobre uma conexo previamente aberta. Antes de se
utilizar a funo, a aplicao do usurio deve checar se o buffer de sada est vazio,
atravs do flag SOCK_TX_BUF_RELEASED do registro Socketstatus. Se estiver,
deve-se escrever os dados a serem enviados na rea de memria apontada por
TCP_TX_BUF e o nmero de bytes dos dados na varivel TCPTxDataCount. O
nmero mximo de bytes que podem ser transmitidos est indicado na constante
MAX_TCP_TX_DATA_SIZE.
void DoNetworkStuff(void)
Funo mais importante, que faz toda a comunicao, e segue o esquema
apresentado pelo fluxograma da Figura 16. Essa funo deve ser chamada
periodicamente pela aplicao, pois acessa vrias flags no controlador de rede e no
microcontrolador. Logo, quanto mais essa funo for chamada freqentemente, melhor
ser o desempenho da pilha TCP/IP.


Figura 16 - Fluxograma da funo DoNetworkStuff()
Esta pilha possui vrias limitaes. Uma delas e muito importante, o no
suporte a mltiplas conexes. Outras limitaes so, a no verificao de erros, a falta
de um suporte a remontagem de pacotes, que so fragmentados. Basicamente uma

41

pilha para redes locais, onde a quantidade de erros bem baixa e que a fragmentao
de pacotes no acontece.
3.6 Pilha uIP (Adam Dunkels)
A pilha uIP foi elaborada por Adam Dunkels com foco em microcontroladores
de 8 bits, e por isso adaptvel a praticamente qualquer microcontrolador encontrado
no mercado. A pilha vem recebendo atualizao constante, ento sempre possvel
verificar novas aplicaes, e ou melhorias na pilha.
A implantao da pilha para o kit de desenvolvimento EasyWeb2 foi realizada
por Paul Curtis, que utilizou o software CrossStudio. Curtis tambm adaptou a pilha
uIP para outro kit com ARM. Atualmente existem diversas implementaes dessa pilha
para os mais diversos microcontroladores existentes atualmente.
Na arquitetura do uIP, o recurso mais escasso a RAM. Com apenas algumas
centenas de Bytes alguns mecanismos tradicionais no so aplicados. No uIP no se
usa alocao dinmica de memria e sim um nico buffer global quem recebe e
transmite os pacotes. O tamanho deste buffer maximizado para suportar o mximo
tamanho de pacotes. O buffer utilizado pelo protocolo, tanto para receber quanto
para enviar pacote IP ao controlador de rede que no caso o CS8900. Outra
informao importante quanto a estrutura do cdigo, que distribudo em mdulos
fazendo que a implementao para diversos tipos de hardware seja feita de forma
fcil e gil, uma vez que pode ser parametrizado para funcionar com hardwares com
pouco mais de 200 bytes de memria RAM.
O funcionamento da pilha inicializa-se com a configurao das portas e timers
do microcontrolador, depois passando a configurar o controlador de rede. Quando um
pacote chega, o controlador de rede coloca o pacote no buffer e aciona a pilha de
protocolo. Caso o pacote tenha dados o microcontrolador ir notificar a aplicao
correspondente. Como o buffer nico, logo que um pacote recebido, ele tem que
ser processado, ou ento armazenado em um segundo buffer. Os pacotes no sero
sobrescritos pelo prximo pacote que chegar. Caso chegue um pacote enquanto a
aplicao est processando, este entrar em fila de espera. O controlador CS8900
tem um buffer que pode armazenar at quatro pacotes, criando uma fila de espera,
para posteriormente envi-lo ao microcontrolador.

42

Algumas funes importantes para o funcionamento da pilha sero descritos a
seguir.
void uIP_appcall(void)
Esta a funo principal, que sempre que um dado recebido, essa funo
chamada. Ela define qual aplicao est sendo solicitada e automaticamente solicita a
funo da aplicao que trate os dados recebidos. A funo identifica qual a aplicao,
lendo o cabealho do frame e posteriormente chama a aplicao correspondente.
void uIP_newdata(void)
Esta funo que avisa a aplicao quando um novo dado recebido, e
sinaliza-se na varivel global uip_conn que tem um dado no buffer.
void uIP_send(void)
Esta funo chamada para a transmisso de dados que esto no buffer.
void uIP_rexmit(void)
Esta a funo que responsvel pela retransmisso de pacotes, que ocorre
quando no recebido o ACK, ou quando acontecer um erro com o pacote enviado.
Apesar de que o controlador de rede do kit EasyWeb2 ter suporte a isso importante
ter isso implementado quando no temos um controlador que tenha esse suporte.
void uIP_close(void)
a funo que fecha um conexo, depois que a aplicao foi executada com
sucesso, e no h mais o que ser transmitido ou recebido. J a funo void
uIP_abort(void), tem a funo de fechar a conexo imediatamente caso ocorra um
erro fatal. Isso pode ocorrer de duas formas; primeiro quando houver estouro de
timeout, ou seja, quando j houve o nmero de tentativas de retransmisso que foi
estipulado na varivel de controle, e segundo se a conexo foi fechada pelo cliente
sem o trmino da transmisso dos dados.
void uIP_listen(void)

43

a funo que faz a manuteno das portas TCP abertas. Caso uma porta
esteja fechada, no ter como se comunicar com a pilha de protocolos TCP/IP.
void uIP_connect(void)
a funo que abre as portas de conexes, configurando a varivel global
uIP_conn com o status da conexo, alm da porta conectada. Isso muito importante
para o controle de todas as conexes ativas.
void uIP_tcpchksum(void)
Esta a funo que faz a verificao de erros no cabealho da pilha TCP, caso
haja algum erro ela automaticamente chama uma funo para que se tenha a
retransmisso do pacote com erro.
void uip_ipchksum(void)
Esta funo faz a verificao de erros no cabealho da pilha IP, e caso haja
erro ela automaticamente chama uma funo para que se tenha a retransmisso do
pacote com erro.
uip_conn
a varivel que controla toda conexo, controlando quais portas esto abertas,
alm de todo as conter todas as flags de controle. basicamente onde est
armazenado todas as informaes referentes as conexes.
O esquema de funcionamento bsico da pilha uIP pode ser observado na
Figura 17. importante entender que as funes bsicas de transmisso,
retransmisso, abertura de portas e as demais que fazem o controle e o
estabelecimento de conexes esto sempre implementadas para que se possa colocar
em funcionamento a pilha de protocolos TCP/IP, mas importante observar que
outras funes de suporte, como as de verificao de erros das pilhas TCP e IP nem
sempre esto implementadas, uma vez que a necessidade definida pela
convenincia do programador e limitadas por seu hardware.

44


Figura 17 - Fluxograma bsico do protocolo uIP


45

4. Resultado e discusso
Muitas diferenas de cdigo podem ser observadas, mas o foco do trabalho
uma anlise qualitativa, especificando os principais pontos de diferenas entre as duas
pilhas. E por fim uma anlise sobre os impactos dessas diferenas para outras
aplicaes.
A primeira diferena referente estrutura do cdigo, em que a pilha de
Andreas Dannenberg tem um cdigo unificado, possuindo poucas funes, e as
funes no possuem muitas parametrizaes como se poderia de ter, dando ao
cdigo maior maleabilidade. J a pilha uIP possui o cdigo distribudo em mdulos,
aos quais podem ser implementados de acordo com a necessidade, e muitas
parametrizaes que contribuem para que a pilha possa ser implementada para
hardware com pouqussima quantidade de RAM (200 bytes).
A pilha uIP tem implementa o suporte ao IPv6, o que faz ela poder ser utilizada
com essa nova verso do protocolo IP. Este protocolo j est sendo implantado e por
enquanto est funcionando lado a lado com o Ipv4. O principal motivo para a
implantao do IPv6 na Internet a necessidade de mais endereos, porque os
endereos livres IPv4 esto se esgotando.
Problemas com conexes mltiplas foram implementadas pelo uIP. O protocolo
de Dannenberg tem suporte somente a uma nica conexo com o servidor web por
vez. Isso bastante restrito, uma vez que hoje vrias pessoas ao redor do mundo
acessam a mesma pgina ao mesmo tempo. Considere uma indstria como exemplo,
que o servidor web a base de dados para vrias mquinas funcionarem, com isso
elas precisam ficar verificando o site sempre. Caso no houvesse suporte a mltiplas
conexes as mquinas no conseguiriam acessar o site, e com isso no teriam acesso
base de dados, gerando uma pane que talvez pudesse resultar na parada da
produo.
Um ponto de bastante ateno a verificao de erros (checksum) no uIP. A
pilha de Dannenberg no realiza verificao de erros. Isso para uma rede bem
estruturada pode no ser relevante, mas quando se pensa que vrias pessoas ao
redor do mundo acessa o website tem-se de levar em conta os erros durante a
transmisso e recepo dos pacotes IP. J o uIP faz essa verificao com um cdigo
bem simples.

46

Apesar de no ser necessariamente uma diferena e sim uma nova
implementao, o uIP tem suporte a UDP, o que pode ser favorvel quando se pensa
em transmisso de dados sem verificao, mas com maior agilidade e velocidade.
Tambm tem suporte a HTTP, Telnet Server e Client, SMTP, alm de suporte a um
sistema de arquivos.
A pilha de Dannenberg possui um ponto crtico que a falta de um sistema de
remontagem de pacotes. Isso de extrema importncia, pois pacotes que passam por
redes diferentes ao longo do caminho podem passar por alguns pontos onde se
fragmenta o pacote para se adequar a rede daquele local. Isso faz com que o servidor
tenha que remont-lo para poder entender o pacote e com isso retransmitir o que foi
solicitado.
A documentao de ambos os projetos so bem elaboradas. O projeto de
Andreas, no se tem documentao, mas possui um cdigo bem comentado, mas
nada alm disso. J o cdigo uIP, tem-se uma documentao extensa, com isso torna-
se fcil, o entendimento da pilha. Isso contribui para que qualquer pessoa que esteja
interessada em utilizar a pilha uIP possa faz-lo sem problemas de entendimento.
A pilha uIP por ter sido desenvolvida sem especificao de microcontroladores
pode ser implementa para vrios microcontroladores diferentes. Apresenta uma
documentao especifica para implementao em qualquer microcontrolador. Outra
diferena, est na arquitetura do cdigo, em que o protocolo uIP mais distribudo,
onde cada aplicao tem vrias funes, j no caso da pilha de Dannenberg, a pilha
tem poucas funes.
As duas pilhas so de cdigo livre, o que citado por ambos os
desenvolvedores. Com isso qualquer pessoa pode utilizar os cdigos para
implementarem seus projetos. As principais diferenas foram compiladas e mostradas
na Tabela 3 para uma melhor visualizao.


47

Tabela 3 - Comparao entre as duas pilhas

Tamanho de cdigo algo que se deve levar bastante em considerao,
devido s limitaes dos microcontroladores. Apesar de serem pilhas de tamanho
reduzido, so bastante considerveis se comparadas com o tamanho total de memria
de programa disponvel. Alm disso, um cdigo da pilha TCP/IP muito grande, limitaria
a aplicao ao qual o projeto ser destinado. Os tamanhos de cdigos das duas pilhas
podem ser observados na Tabela 4 para efeito comparativo.
Tabela 4 - Tamanho de cdigo das pilhas
Pilhas
Tamanho
Em Bytes
Usado da memria
do MSP430
uIP 11 096 18,05%
Pilha de Andreas 8 906 13,14%

Pode se ver que a pilha uIP ocupa um espao de cdigo maior, e isso
totalmente explicado pelas muitas funcionalidades a mais, que j foram discutidas, que
ele possui. Mas mesmo assim o cdigo bem compacto quando comparado com
pilhas TCP/IP para computadores do tipo PC.

48

Agora analisando o uso de memria RAM das duas pilhas, temos um cenrio
bem parecido, devido as duas possuir um nico buffer local, com isso deve ser
armazenado todo o pacote TCP/IP que est sendo recebido.
Um teste realizado foi o de colocar duas pginas com tamanhos diferentes,
tentando forar diferentes tamanhos de pacotes TCP/IP transportados. Por exemplo
usando uma pgina com apenas 528 bytes e outra com 2567 bytes de tamanho
efetivo, temos os resultados expressos abaixo na Tabela 5. Essas medidas foram
feitas utilizando a funo de DEBUG que os compiladores possuem. No caso o
software principal que chama a funo foi desprezado para no comprometer as
medidas.
Tabela 5 - Uso de memria RAM
Uso de memria RAM (em bytes)
Tamanhos de pginas Andreas uIP
WebPage I (528 bytes) 442 439
WebPage II (2567 bytes) 1328 1327

Um teste que visa mostrar a conectividade com o dispositivo, foi o comando
ping. Este comando utiliza o protocolo ICMP para testar a conectividade entre
equipamentos. Seu funcionamento consiste no envio de pacotes para o equipamento e
de destino e na escuta das respostas. Utilizando o comando ping para testar as
conectividades entre o computador e o dispositivo depois de implementas ambas as
pilhas obteve-se os resultados das Figura 18 para a pilha de Andreas Dannenberg e a
Figura 19 para a pilha uIP.

49


Figura 18 - Resposta da pilha de Andreas Dannenberg ao comando ping


Figura 19 - Resposta da pilha uIP ao comando ping
Para verificar mltiplas conexes, foi utilizada uma tcnica simples, que
consiste em colocar uma pgina com um tempo de atualizao na faixa de um dois
segundos, para ficar atualizando constantemente. Este tempo foi estimado utilizando
um software (Firebug v.1.4.5), instalado juntamente com o navegador de internet
Mozilla Firefox, mede o tempo de abertura de uma pgina, desde a solicitao at o
carregamento completo. Efetuando o teste algumas vezes a mdia de tempo de
abertura foi de 2,03 s. Logo se utilizou tempo de atualizao de dois segundos.

50

Abrindo a pgina em um computador, a mesma ficou atualizando a cada dois
segundos. Ao mesmo tempo em outro computador foi solicitada a pgina e verificada
se a mesma foi recebida. Alm de tentar abrir a pgina, foi utilizando o comando ping
para verificar a conectividade entre o computador e o dispositivo. Para a pilha de
Andreas Dannenberg a pgina solicitada no segundo computador no obteve
resposta, e o comando ping teve como resposta a Figura 20. J a pilha uIP obteve
resposta ao comando ping conforme Figura 21.

Figura 20 Teste mltiplas conexes da pilha de Andreas Dannenberg


Figura 21 Teste mltiplas conexes da pilha uIP


51

Uma aplicao bastante interessante e que foi estruturada para podermos
exemplificar foi a implementao de um cliente SMTP utilizando a pilha uIP. O SMTP
um protocolo padro para envio de emails atravs da internet. relativamente simples
de ser implementado, e tem como referncias a RFC282, na qual toda a descrio
detalhada.
O protocolo baseado em comandos enviados pelo cliente e respostas dadas
pelo servidor. Sempre se espera a resposta de um comando antes de mandar um
novo comando. Os comandos e resposta so sempre terminados pelo caractere
Carriage Return (CR). Todas as respostas do servidor possuem duas partes: o
cdigo de retorno e a mensagem "Human Readable" (legvel por humanos) sendo
que o cdigo usado para identificar o tipo de mensagem por programas. Cdigos
comeados com 2 indicam sucesso, 3 indicam sucesso, mas deve-se enviar mais
dados para finalizar a operao, e 4 ou 5 so erros.



52

5. Concluso
O objetivo principal deste trabalho foi a comparao das duas pilhas de
protocolos TCP/IP.
Para tanto foi importante o estudo individual de ambas as pilhas de protocolos.
Com isso conclui-se que diante de inmeros fatos citados no capitulo trs, a pilha uIP
mais robusta, uma vez tambm que uma pilha melhorada em relao primeira.
Outros fatores so as mais diversas aplicaes que so suportadas em seu cdigo
nativo.
No se pode dizer sobre melhor ou pior. Pois depende necessariamente da
aplicao foco de qualquer projeto, para se definir a melhor pilha. Uma vez que a
aplicao seja somente um servidor web local, a pilha de Andreas Dannenberg
suporta com tranqilidade, pois no necessita de remontagem de pacote e a
quantidade de erros bem pequena, mas se for um servidor que ser acessado de
qualquer parte do mundo, prefere-se a pilha uIP, por conter remontagem de pacotes e
verificao de erros.
Utilizando as pilhas, tanto de Andreas quanto a uIP pode se implementar vrias
aplicaes desde um simples servidor web at projetos de armazenamento em
massa. Desde que precise se conectar com a internet, qualquer aplicao possvel,
mas sempre considerando algumas limitaes.
Hoje em dia a mobilidade tornou-se algo do nosso dia-a-dia, mas as vezes
estamos distrados e nos perdemos diante de tanta mobilidade. Este o caso de
documentos importantes, que as vezes trabalhamos em vrios lugares e nem sempre
na mesma mquina. Com isso uma aplicao interessante a ser desenvolvida, um
servidor FTP, ou mesmo um NAS (Network-attached storage), onde se conecta
diretamente na rede uma unidade de armazenamento (HD). Com um microcontrolador
isso seria possvel utilizando memrias flash. Hoje existem no mercado controladores
para memrias flash que se adaptam a qualquer microcontrolador possibilitando leitura
e escrita de dados. Para isso utiliza-se uma aplicao j disponvel na pilha uIP para
implantao de um servidor FTP.


53

Referencia Bibliogrfica
1. Tanenbaum, Andrew S. Computer Networks. s.l. : Prentice Hall, 2002.
2. IETF. IETF. IETF Web Site. [Online] [Citado em: 02 de 11 de 2009.]
http://tools.ietf.org.
3. Olimex. Olimex. Olimex Web Site. [Online] [Citado em: 02 de 11 de 2009.]
http://www.olimex.com/dev/msp-easyweb2.html.
4. Instruments, Texas. Texas Instruments. Texas Instruments Web Site. [Online]
[Citado em: 02 de 11 de 2009.] http://focus.ti.com/lit/ds/symlink/msp430f149.pdf.
5. Logics, Cirrus. Cirrus Logics. Cirrus Logics Web Site. [Online] [Citado em: 02 de
11 de 2009.] http://cirrus.com/en/products/pro/detail/P46.html.
6. Logic's, Cirrus. Cirrus Logic's. Cirrus Logic's Web Site. [Online]
http://cirrus.com/en/pubs/proDatasheet/CS8900A_F4.pdf.
7. IANA. IANA. IANA Web Site. [Online] [Citado em: 02 de 11 de 2009.]
http://www.iana.org/protocols/.