UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA DE COMPUTAO E AUTOMAO

Projeto de um sistema microcontrolado utilizando Internet embarcada para monitoramento remoto em tempo real de temperatura e disponibilizao dos dados na WEB atravs de conexo de rede

JOHNNY CEZAR MARAL DOS SANTOS

Orientador: Prof. D.Sc. Sergio Vianna Fialho

Natal-RN, Julho de 2009

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA DE COMPUTAO E AUTOMAO

Projeto de um sistema microcontrolado utilizando Internet embarcada para monitoramento remoto em tempo real de temperatura e disponibilizao dos dados na WEB atravs de conexo de rede

JOHNNY CEZAR MARAL DOS SANTOS

Orientador: Prof. D.Sc. Sergio Vianna Fialho

Trabalho de Concluso de Curso apresentado ao Programa de Graduao em Engenharia de Computao da Universidade Federal do Rio Grande do Norte como parte dos requisitos para a obteno do Ttulo de Engenheiro de Computao.

Natal-RN, Julho de 2009 ii

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA DE COMPUTAO E AUTOMAO

Trabalho de Concluso de Curso apresentado banca examinadora composta pelos seguintes membros:

______________________________________________________ Prof. D.Sc. Sergio Vianna Fialho Orientador DCA / UFRN

______________________________________________________ Prof. D.Sc. Edson Moreira Silva Neto CAJ/UFRN

______________________________________________________ Prof. Dr. Glucio Bezerra Brando DCA / UFRN

Natal-RN, Julho de 2009 iii

AGRADECIMENTOS
Agradeo primeiramente a Deus por ter me guiado e iluminado para que eu fizesse as escolhas corretas, que geralmente no so as mais fceis. minha me, Walmira Judith Maral dos Santos, pelo total e incondicional amor e carinho, que me fazem ter nimo e foras para superar qualquer obstculo, pela privilegiada condio de ser to amado e querido. Ao meu pai, Joo Batista dos Santos, pela total confiana e apoio nos momentos mais difceis da minha vida, pelo exemplo de homem com carter e integro que e pelo enorme orgulho que sinto por ser seu filho. Pai e Me devo a vocs todas as minhas virtudes e qualidades, devo a vocs tudo de bom que sou e que ainda sonho em ser. Pai e me sem vocs seria impossvel! Aos grandes amigos e colegas de curso, que certamente contriburam muito para minha formao como pessoa e como aluno de graduao. Em especial Anna Giselle Cmara Dantas Ribeiro, Daniel Lopes Martins, Ellon Paiva Mendes, Mrio Andrade Viera de Melo Neto e Vinicius Samuel Valrio de Souza, que me acompanharam durante quatro anos e meio e fizeram essa trajetria ser divertida, prazerosa e inesquecvel. Eu devo muito a vocs! Agradeo tambm a Tiago Monteiro da Silva por gentilmente ter me cedido o modelo de TCC e ter me auxiliado na utilizao do mesmo. Aos demais colegas e amigos no citados, vocs com certeza no foram esquecidos, acreditem! Ao meu orientador Prof. D.Sc Sergio Vianna Fialho, pela grande pacincia dedicada a mim durante mais de dois anos em que fui seu aluno de iniciao cientfica. No apenas por isso, mas pelo exemplo de carter, tica, inteligncia, humildade, grande conhecimento e competncia, que presenciei durante mais de dois anos de convivncia. H dois anos eu fiz uma escolha por um orientador, certamente poderia ter escolhido outros e provavelmente tambm seria um bom aluno de iniciao cientfica, mas no to bom quanto sou hoje: eu fiz a melhor escolha. Ao curso de Engenharia de Computao da UFRN pela tima formao acadmica. Aos professores excelentes e brilhantes do Departamento de Engenharia de Computao e Automao (DCA). A alguns igualmente excelentes e brilhantes do Departamento de Matemtica e Informtica Aplicada (DIMAP). Aos colegas, amigos e funcionrios do PoP-RN/RNP. minha portuguesa favorita, Angela Vitria Guerreiro da Silva, por todo carinho, companheirismo, diverso, suporte e afagos. Sinto muitas saudades de voc, espero que um dia possamos estar juntos novamente para compensar todos os anos, dias, minutos e segundos de distncia. s minhas amigas Thays Magnlia e Priscila Fortunato, por terem recentemente vindo de to longe me proporcionar alegria, tranqilidade, afagos, mimos, carinho... Foi muito bom estar com vocs, eu precisava disso (e j estou sentido falta... Voltem, vai...)! Obrigado. Por fim agradeo a John Von Neumann, Alan Mathison Turing e Randy Rhoads, por terem dedicado suas vidas a obras que fizeram a minha vida ter um sentido. iv

EPGRAFE

Se voc pensa que pode ou sonha que pode, comece. Ousadia tem genialidade, poder e mgica. Ouse fazer e o poder lhe ser dado. Johann Wolfgang Von Goethe

RESUMO
O presente Trabalho de Concluso de Curso apresenta os estudos iniciais relacionados ao projeto de um circuito microcontrolado para monitoramento de temperatura utilizando a tecnologia Internet embarcada. Apresenta tambm, o projeto de um software para aquisio remota de dados e um sistema WEB para monitoramento de temperatura. O sistema aqui proposto, em um futuro prximo, poder ser utilizado para possibilitar o monitoramento remoto e em tempo real de temperatura de um determinado ambiente. Dessa forma, uma pessoa poder, remotamente, obter informaes sobre a temperatura do ambiente monitorado a qualquer momento, necessitando apenas de conexo com a Internet e de um navegador WEB para acessar o sistema.

Palavras-chaves: Microcontroladores. Internet embarcada. Redes de computadores. Daemon. WEB.

vi

ABSTRACT
The present work of course conclusion presents initial studies related to the design of a microcontroller circuit for temperature monitoring using the Internet embedded technology. Also presents the design of a software for remote data acquisition and a WEB system for temperature monitoring. The system proposed here, in the near future, could be used to enable remote and real-time temperature monitoring of a environment. Thus, a person could, remotely, obtain information about temperature of the monitored environment at any time, requiring only Internet connection and a Web browser to access the system.

Key-Words: Microcontroller. Internet embedded. Computer networks. Daemon. WEB.

vii

SUMRIO
EPGRAFE ....................................................................................................................................... v RESUMO ........................................................................................................................................vi ABSTRACT.....................................................................................................................................vii SUMRIO.....................................................................................................................................viii LISTA DE FIGURAS.........................................................................................................................xii LISTA DE TABELAS.......................................................................................................................xvii 1. INTRODUO ............................................................................................................................ 1 1.1 CONTEXTUALIZAO........................................................................................................... 1 1.2. JUSTIFICATIVA .................................................................................................................... 2 1.3. OBJETIVOS .......................................................................................................................... 2 1.4. METODOLOGIA................................................................................................................... 3 1.5. ESTRUTURA ........................................................................................................................ 4 2. INTERNET EMBARCADA............................................................................................................. 5 2.1. INTRODUO ..................................................................................................................... 5 2.2. APLICAES........................................................................................................................ 5 2.3. PLATAFORMAS EXISTENTES PARA INTERNET EMBARCADA............................................... 7 2.3.1. PICDEM.NET 2 ............................................................................................................. 7 2.3.2. EXPLORER16 BR PIC24FJ128GA010-I/PT..................................................................... 8 2.3.3. MAGICPIC BOARD........................................................................................................ 9 2.3.4. DSPIC SIGMA 128 ...................................................................................................... 10 3. COMPONENTES DE HARDWARE ............................................................................................. 11 3.1. MICROCONTROLADOR ..................................................................................................... 11 3.1.1. CARACTERSTICAS...................................................................................................... 12 3.1.2. ARQUITETURA INTERNA............................................................................................ 14 3.1.3. PINAGEM................................................................................................................... 17 viii

3.1.4. CARACTERSTICAS ELTRICAS.................................................................................... 18 3.1.5. CICLOS DE MQUINA ................................................................................................ 19 3.1.6. ORGANIZAO DA MEMRIA DE PROGRAMA ......................................................... 19 3.1.7. ORGANIZAO DA MEMRIA DADOS ...................................................................... 20 3.1.8. CONFIGURAES DO OSCILADOR............................................................................. 22 3.1.9. PERIFRICOS .............................................................................................................. 23 3.2. SENSOR DE TEMPERATURA.............................................................................................. 30 3.3. DISPLAY LCD ..................................................................................................................... 31 3.4. CONTROLADOR ETHERNET............................................................................................... 33 3.5. INTERFACE DE REDE ......................................................................................................... 36 4. DESENVOLVIMENTO DO SISTEMA MICROCONTROLADO ....................................................... 37 4.1. METODOLOGIA................................................................................................................. 37 4.2. FERRAMENTAS UTILIZADAS ............................................................................................. 39 4.2.1. MPLAB IDE................................................................................................................. 39 4.2.2. COMPILADOR MPLAB C18 PARA MICROCONTROLADORES PIC18F.......................... 40 4.2.3. PROTEUS VSM ........................................................................................................... 40 4.3. PROJETO DE HARDWARE .............................................................................................. 42 4.3.1. CIRCUITO MICROCONTROLADO PARA MONITORAMENTO DE TEMPERATURA ....... 43 4.3.2. CIRCUITO MICROCONTROLADO PARA MONITORAMENTO DE TEMPERATURA E DISPONIBILIZAO DOS DADOS ATRAVS DE CONEXO DE REDE..................................... 45 4.4. PROJETO DE SOFTWARE ............................................................................................... 48 4.4.1. SOFTWARE EMBARCADO PARA INTERFACEAMENTO COM SENSOR DE TEMPERATURA LM35 .......................................................................................................... 48 4.4.2. SOFTWARE EMBARCADO PARA INTERFACEAMENTO COM DISPLAY LCD ............. 60 4.4.3. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA .............. 67 4.4.4. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVS DE UM SERVIDOR HTTP MICROCONTROLADO ................................................................... 69

ix

4.4.5. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVS DE UM CLIENTE TCP MICROCONTROLADO......................................................................... 88 4.4.6. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVS DE CLIENTE TCP E SERVIDOR HTTP MICROCONTROLADOS ................................................ 91 5. DAEMON PARA MONITORAMENTO REMOTO DE TEMPERATURA...................................... 93 5.1. CONSIDERAES TERICAS ............................................................................................. 93 5.1.1. DAEMON ................................................................................................................... 93 5.1.2. UM POUCO SOBRE PROGRAMAO CONCORRENTE............................................... 94 5.1.3. PROCESSOS................................................................................................................ 94 5.1.4.THREADS ................................................................................................................. 96 5.1.5. PROCESSOS X THREADS ......................................................................................... 98 5.1.6. COMUNICAO INTERPROCESSOS ........................................................................... 99 5.2. METODOLOGIA............................................................................................................... 101 5.2.1. ECLIPSE IDE CDT ...................................................................................................... 102 5.2.2. MYSQL ..................................................................................................................... 103 5.2.3. POSIX THREADS.................................................................................................... 103 5.2.4. BERKELEY SOCKETS.................................................................................................. 104 5.2.5. POSTFIX ................................................................................................................... 104 5.2.6. DEBIAN 4 ETCH ........................................................................................................ 104 5.3. ESPECIFICAO .............................................................................................................. 105 5.3.1. DIAGRAMA DE CASOS DE USO ................................................................................ 105 5.3.2. DIAGRAMA DE CLASSES........................................................................................... 106 5.3.3. DIAGRAMA DE TRANSIO DE ESTADOS ................................................................ 108 5.3.4. DIAGRAMA DE ATIVIDADES..................................................................................... 109 5.4. IMPLEMENTAO .......................................................................................................... 112 6. SISTEMA WEB PARA MONITORAMENTO DE TEMPERATURA ............................................... 114 6.1. CONSIDERAES TERICAS ........................................................................................... 114 6.1.1. JAVA......................................................................................................................... 114 x

6.1.2. MVC E ARQUITETURA EM 3 CAMADAS................................................................... 119 6.1.3. PADRES DE PROJETO ............................................................................................ 121 6.1.4. PADRES UTILIZADOS ............................................................................................. 126 6.2. METODOLOGIA............................................................................................................... 131 6.2.1. NETBEANS IDE ......................................................................................................... 131 6.2.2. JSF (JAVA SERVER FACES) ........................................................................................ 132 6.2.3. HIBERNATE .............................................................................................................. 133 6.2.4. JFREECHART............................................................................................................. 134 6.2.5. JASPER REPORTS E IREPORT ............................................................................. 134 6.2.6. GLASSFISH ............................................................................................................... 135 6.3. ESPECIFICAO .............................................................................................................. 135 6.3.1. DIAGRAMA DE CASOS DE USO ................................................................................ 136 6.3.2. DIAGRAMA DE CLASSE: ARQUITETURA EM TRS CAMADAS .................................. 137 6.3.3. DIAGRAMA DE CLASSE: ARQUITETURA REFINADA COM PADRES DE PROJETO ... 138 6.3.4. DIAGRAMA DE CLASSE: ARQUITETURA COM AS TECNOLOGIAS JSF E HIBERNATE. 141 7. TESTES E RESULTADOS .......................................................................................................... 143 7.1. SERVIDOR HTTP MICROCONTROLADO........................................................................... 145 7.1.1. SERVIDOR HTTP MICROCONTROLADO ENVIANDO UMA PGINA HTML................ 145 7.1.2. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS A REQUISIES ASSNCRONAS AJAX........................................................................................................... 146 7.1.3. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS AO PING ......... 147 7.2. CLIENTE TCP MICROCONTROLADO ................................................................................ 148 8. CONCLUSES......................................................................................................................... 150 REFERNCIAS BIBLIOGRFICAS ................................................................................................. 154

xi

LISTA DE FIGURAS
Figura 2.1 - Infra-estrutura tradicional para um sistema de acionamento ou monitoramento via WEB. .............................................................................................................................................. 6 Figura 2.2 - Infra-estrutura proposta pela Internet embarcada para um sistema de acionamento ou monitoramento via WEB.................................................................................... 6 Figura 2.3 - Placa Microchip PICDEM.net 2................................................................................... 7 Figura 2.4 - Placa Labtools Explorer16BR...................................................................................... 8 Figura 2.5 - Placa Microgenius MagicPic board. ........................................................................... 9 Figura 2.6 - Placa Exsto DsPIC Sigma 128. ................................................................................... 10 Figura 3.1 - Arquitetura interna do PIC 18F2620/18F4620......................................................... 16 Figura 3.2 - Pinagem do microcontrolador PIC18F2620. ............................................................ 17 Figura 3.3 - Pinagem do microcontrolador PIC18F4620. ............................................................ 18 Figura 3.4 - Mapa da memria de programa e pilha dos microcontroladores PIC18F2620/PIC18F4620............................................................................................................. 20 Figura 3.5 - Memria de dados dos microcontroladores PIC18F2620/PIC18F4620. .................. 21 Figura 3.6 - Registradores de Funo Especial (SFR) dos microcontroladores PIC18F2620/PIC18F4620............................................................................................................. 22 Figura 3.7 - Conexo entre o cristal e o microcontrolador na configurao "Oscilador a Cristal". ..................................................................................................................................................... 23 Figura 3.8 - Modelo genrico de PORT dos microcontroladores PIC18F2620 e PIC18F4620 ..... 24 Figura 3.9 - Diagrama de blocos do Timer 0 operando no modo 8 bits...................................... 25 Figura 3.10 - Diagrama de blocos do Timer 0 operando no modo 16 bits.................................. 25 Figura 3.11 - Diagrama de blocos do mdulo conversor A/D. .................................................... 27 Figura 3.12 - Diagrama de blocos do MSSP no modo SPI. .......................................................... 28 Figura 3.13 - Exemplo de comunicao entre microcontroladores utilizando interface SPI. ..... 29 Figura 3.14 - Encapsulamento do LM35 utilizado....................................................................... 30 Figura 3.15 - Configurao em que o LM35 foi utilizado. ........................................................... 31 Figura 3.16 - Display LCD JHD204................................................................................................ 31 xii

Figura 3.17 - Diagrama de blocos simplificado do controlador Ethernet ENC28J60. ................. 33 Figura 3.18 - Tpico circuito de aplicao do ENC28J60. ............................................................. 34 Figura 3.19 - Componentes padronizados necessrios para estabelecer uma interface Ethernet. ..................................................................................................................................................... 34 Figura 3.20 - Esquema de comunicao entre microcontrolador e ENC28J60 utilizando transdutor de nvel unidirecional................................................................................................ 35 Figura 3.21 - Pinagem do controladdor Ethernet ENC28J60. ..................................................... 35 Figura 3.22 - Interface de rede 100/10 Base-Tx RJ45. ................................................................ 36 Figura 4.1 - Ambiente de trabalho do MPLAB IDE. ..................................................................... 39 Figura 4.2 - Placa PICDEM2+ da Microchip. ................................................................................ 41 Figura 4.3 - Placa PICDEM2+ no ambiente ISIS e simulada atravs do Proteus VSM. ................ 41 Figura 4.4 - Esboo da arquitetura do "hardware" proposto. .................................................... 42 Figura 4.5 - Simulao do circuito microcontrolado para monitoramento de temperatura...... 43 Figura 4.6 - Circuito para monitoramento de temperatura montado em "protoboard". .......... 44 Figura 4.7 - Simulao do circuito microcontrolado para monitoramento de temperatura e disponibilizao dos dados via Internet. ..................................................................................... 45 Figura 4.8 - Pgina para monitoramento de temperatura gerada por um servidor HTTP microcontrolado.......................................................................................................................... 46 Figura 4.9 - Comunicao entre um cliente TCP microcontrolado e um servidor TCP remoto baseado em um PC...................................................................................................................... 47 Figura 4.10 - Configuraes possveis dos canais A/D para o PIC18F2620. ................................ 50 Figura 4.11 - Fluxograma do "software" embarcado para interfaceamento do microcontrolador com o sensor LM35. .................................................................................................................... 59 Figura 4.12 - Procedimentos necessrios para a inicializao do display LCD............................ 61 Figura 4.13 - Endereamento direto de um display LCD 16x2. ................................................... 62 Figura 4.14 - Relao entre posio e valor hexadecimal que deve ser enviado ao display LCD 16x2 para posicionamento manual de cursor............................................................................. 62 Figura 4.15 - Relao entre posio e valor hexadecimal que deve ser enviado ao display LCD 20x4 para posicionamento manual de cursor............................................................................. 62

xiii

Figura 4.16 - Fluxograma do "software" embarcado para interfaceamento do microcontrolador com o display LCD. ...................................................................................................................... 66 Figura 4.17 - Fluxograma do "software" embarcado para monitoramento de temperatura..... 68 Figura 4.18 - Organizao da pilha TCP/IP da Microchip. ........................................................... 70 Figura 4.19 - Comparao entre a estrutura da pilha TCP/IP da Microchip e o modelo de referncia TCP/IP......................................................................................................................... 70 Figura 4.20 - Formato de armazenamento utilizado pelo MPFS................................................. 71 Figura 4.21 - Formato da entrada FAT utilizada pelo MPFS........................................................ 72 Figura 4.22 - Formato do bloco de dados do MPFS. ................................................................... 72 Figura 4.23 - Resultado do comando "mpfs /?" no utilitrio MPFS.exe ..................................... 73 Figura 4.24 Tarefas necessrias para o monitoramento de temperatura. .............................. 82 Figura 4.25 - Modelo clssico de visualizao de contedos na WEB. ....................................... 82 Figura 4.26 - Modelo AJAX para visualizao de contedo na WEB. .......................................... 83 Figura 4.27 - Fluxo de dados ao longo do tempo em uma aplicao WEB clssica. ................... 84 Figura 4.28 - Fluxo de dados ao longo do tempo em uma aplicao WEB com AJAX. ............... 84 Figura 4.29 - Grfico comparativo dos dados transferidos ao longo do tempo entre uma aplicao WEB clssica e outra com AJAX................................................................................... 84 Figura 4.30 - Fluxograma do "software" embarcado para monitoramento de temperatura e disponibilizao dos dados utilizando um servidor HTTP microcontrolado. .............................. 87 Figura 4.31 Diagrama UML de transio de estados do cliente TCP microcontrolado............ 89 Figura 4.32 - Fluxograma do "software" embarcado para monitoramento de temperatura e disponibilizao dos dados atravs de um cliente TCP microcontrolado. .................................. 90 Figura 4.33 - Fluxograma do "software" embarcado para monitoramento de temperatura atravs de um servidor HTTP e cliente TCP microcontrolados. .................................................. 92 Figura 5.1 - Processos em um ambiente multiprogramado........................................................ 95 Figura 5.2 - Possveis estados de um processo no Linux............................................................. 95 Figura 5.3 - Duas formas de se criar trs fluxos de execuo usando processos e threads. ... 96 Figura 5.4 - Possveis estados de um "thread" no Linux. ............................................................ 97 Figura 5.5 - Comparao em termos de tempo para criao de "threads" e processos. ........... 98 xiv

Figura 5.6 - Logo do projeto Eclipse IDE CDT. ........................................................................... 102 Figura 5.7 - Algumas telas do Eclipse IDE CDT. ......................................................................... 102 Figura 5.8 - Logo do SGBD MySQL............................................................................................. 103 Figura 5.9 - Logo do servidor de e-mail Postfix. ........................................................................ 104 Figura 5.10 - Logo do sistema operacional Debian/Linux. ........................................................ 104 Figura 5.11 - Diagrama de casos de uso do JDaemon............................................................... 106 Figura 5.12 - Diagrama de classes do JDaemon. ....................................................................... 107 Figura 5.13 - Diagrama de transio de estados do JDaemon. ................................................. 109 Figura 5.14 - Diagrama de atividades do JDaemon................................................................... 111 Figura 6.1 - APIs fornecidas pela plataforma JEE. ..................................................................... 115 Figura 6.2 - Dois exemplos de aplicaes JEE multicamadas. ................................................... 116 Figura 6.3 - Exemplo de interao entre um cliente e uma aplicao WEB. ............................ 117 Figura 6.4 MVC: flexibilidade na apresentao do mesmo conjunto de dados..................... 119 Figura 6.5 - Representao de uma arquitetura em trs camadas utilizando diferentes tecnologias de viso e persistncia........................................................................................... 120 Figura 6.6 - Relacionamento entre as camadas do MVC. ......................................................... 121 Figura 6.7 - Interface grfica do Netbeans................................................................................ 132 Figura 6.8 - Funcionamento de uma interface de usurio com o JSF. ...................................... 133 Figura 6.9 - Exemplos de grficos produzidos com o JFreeChart.............................................. 134 Figura 6.10 - Logo do servidor de aplicaes Glassfish. ............................................................ 135 Figura 6.11 - Diagrama de casos de uso do sistema WEB......................................................... 137 Figura 6.12 - Arquitetura em trs camadas utilizando a nomenclatura MVC. ......................... 138 Figura 6.13 - Arquitetura em trs camadas refinada com padres de projeto. ....................... 140 Figura 6.14 - Arquitetura com as tecnologias JSF e Hibernate. ................................................ 142 Figura 7.1 - Ambiente montado para testes de desempenho. ................................................. 144 Figura 7.2 - Cenrio lgico para os testes de desempenho. ..................................................... 144 Figura 7.3 - Desempenho do servidor HTTP microcontrolado servindo uma pgina HTML..... 146 xv

Figura 7.4 - Desempenho do servidor HTTP microcontrolado respondendo apenas requisies AJAX........................................................................................................................................... 146 Figura 7.5 - Desempenho do servidor HTTP microcontrolado respondendo apenas ao comando "ping"......................................................................................................................................... 147 Figura 7.6 - Desempenho do cliente TCP microcontrolado. ..................................................... 148

xvi

LISTA DE TABELAS
Tabela 3.1 - Capacidade de memria dos microcontroladores PIC18F2620 e PIC18F4620. ...... 13 Tabela 3.2 - Perifricos dos microcontroladores PIC18F2620 e PIC18F4620. ............................ 13 Tabela 3.3 - Caractersticas eltricas dos microcontroladores PIC18F2620 e PIC18F4620. ....... 18 Tabela 3.4 - Relao entre o modo de oscilao, a freqncia do cristal e os capacitores necessrios. ................................................................................................................................. 23 Tabela 3.5 - Pinagem do Display LCD JHD204. ............................................................................ 32 Tabela 4.1 - Parcela de tenso que cada "bit" representa em um conversor A/D de 4 bits com referncia em 5 Volts. ................................................................................................................. 49 Tabela 4.2 Mxima freqncia possvel para permitir a operao correta do conversor A/D.53 Tabela 4.3 - Descrio das principais funes do compilador C18 relacionadas ao conversor A/D. ............................................................................................................................................. 54 Tabela 4.4 - Descrio das principais funes do compilador C18 relacionadas comunicao com display LCD. ......................................................................................................................... 63 Tabela 4.5 - Tempo de CPU hipottico para atividades necessrias para realizar o monitoramento de temperatura. ............................................................................................... 81 Tabela 6.1 - Padres de projeto de criao............................................................................... 123 Tabela 6.2 - Padres de projeto estruturais.............................................................................. 124 Tabela 6.3 - Padres de projeto comportamentais. ................................................................. 125

xvii

1. INTRODUO
O presente trabalho diz respeito a uma atividade de estgio supervisionado. Este estgio possuiu uma carga horria muito superior necessria para a concluso da atividade acadmica de estgio supervisionado. Durante mais de dois anos e meio como bolsista RNP (Rede Nacional de Pesquisa) do PoP-RN, participei de dois grupos de trabalho, a saber: Multimdia e Internet embarcada. No grupo Multimdia desenvolvi o SAGA (SANTOS; FIALHO, 2008A), que um Sistema WEB para administrao e gerenciamento remoto e em tempo real de servidores VoIP baseados no Asterisk PBX. Esse sistema atualmente responsvel pela administrao do servio VoIP no PoP-RN. Tambm desenvolvi o WEBSec (SANTOS; FIALHO, 2008B), que um mdulo de segurana para preveno, deteco e auditoria de ataques WEB, utilizado no SAGA para garantir integridade e confiabilidade na administrao do servio VoIP. No grupo Internet embarcada desenvolvi os estudos e componentes que so apresentados no presente trabalho.

1.1 CONTEXTUALIZAO
O monitoramento a distncia de ambientes vem sendo uma atividade de relevante importncia, to logo os avanos tecnolgicos o permitiram. Monitorar um ambiente que possua, por exemplo, aparelhos eletroeletrnicos caros, uma forma adicional de aumentar a garantia de operacionalidade e disponibilidade dos servios providos por esse ambiente. A rea de controle de processos j se encontra bem consolidada e conta com uma quantidade significativa de tcnicas e procedimentos variados para a consecuo de seus objetivos. Assim, no nenhuma novidade a implantao de um sistema automatizado para monitoramento de temperatura em determinados ambientes. Entretanto, a digitalizao desses procedimentos, com o uso de microcontroladores e sensores adequados, permite que se obtenha e se armazene os dados referentes ao processo de controle sob forma digital. O passo seguinte seria a disponibilizao desses dados para acesso remoto atravs das redes de computadores. Essa integrao entre os mecanismos tradicionais de monitoramento e a disseminao dos dados obtidos nesse processo atravs da Internet se constitui no foco do presente projeto. A principal tecnologia utilizada no mbito deste trabalho a Internet embarcada, que consiste basicamente na conexo de sistemas embarcados Internet. Atravs do uso desta tecnologia, pretende-se possibilitar a integrao entre os mecanismos tradicionais de monitoramento e a disseminao dos dados atravs da Internet. Essencialmente, este trabalho apresenta o projeto de um circuito microcontrolado utilizando Internet embarcada, para monitoramento de temperatura e disponibilizao desses dados atravs da rede de computadores. Alm disso, apresenta a implementao dos programas embarcados, para disponibilizar os dados na Internet atravs de servidor HTTP e cliente TCP microcontrolados. Tambm fazem parte do escopo desse trabalho, a especificao formal e a 1

implementao inicial de um daemon para aquisio remota de temperatura via Internet e de um sistema de informao baseado na WEB para monitoramento de temperatura.

1.2. JUSTIFICATIVA
A Internet embarcada se revela como uma tendncia mundial e uma tecnologia recente e pouco utilizada atualmente. Nesse sentido, importante que se formem recursos humanos para que essa tecnologia possa ser estudada e dominada. A possibilidade de se desenvolver sistemas que obtm dados fsicos de um determinado ambiente e utilizam a Internet para transmiti-los, apenas uma pequena amostra do que essa tecnologia to promissora vem a acrescentar na rea de redes de computadores e sistemas embarcados. Hoje, j possvel, por exemplo, se criar programas cliente/servidor que, utilizando a rede de computadores, verificam status, acionam e desligam dispositivos remotamente atravs de uma simples interface de rede. Investir no estudo dessa tecnologia um grande passo para que, em um futuro prximo, se possa implementar sistemas com caractersticas inovadoras e totalmente integrados Internet. No contexto do PoP-RN, o sistema de monitoramento de temperatura proposto, alm de contribuir para a manuteno da infra-estrutura instalada, possibilitar que uma anlise de trfego, desempenho e banda possa ser avaliada, em conjunto com o comportamento da temperatura. Por exemplo, pode se verificar se nos horrios de pico de trfego houve uma sobrecarga nos equipamentos da sala de servidores, de tal forma a elevar a temperatura do ambiente. Outro aspecto de interesse se refere possibilidade de notificar, o mais rpido possvel, o administrador do sistema, sobre algum comportamento inadequado do sistema de refrigerao. Essa no uma situao to incomum, uma vez que as freqentes quedas do fornecimento de energia eltrica ocorridas na UFRN, muitas vezes provocam o desarme dos disjuntores dos circuitos que acionam os equipamentos de refrigerao do PoP-RN. Quando essa situao ocorre durante a noite ou em um fim-de-semana, as conseqncias podem ser danosas operao desse setor.

1.3. OBJETIVOS
O PoP-RN possui uma sala com equipamentos complexos e de alto custo que so utilizados para interconexo de redes de computadores. Esses equipamentos so responsveis pela comunicao, via Internet, de vrias das instituies de ensino superior e pesquisa do RN. Para o seu funcionamento adequado, esses aparelhos necessitam de um ambiente com boa refrigerao e, conseqentemente, rigoroso controle de temperatura e para isso o sistema proposto foi idealizado. Assim, esse projeto tem como objetivo principal possibilitar, em um futuro prximo, o monitoramento do comportamento da temperatura na sala de servidores do PoP-RN e possibilitar a disseminao desses dados pela rede, a fim possibilitar a visualizao remota e em tempo real dos mesmos.

Tambm so objetivos do presente trabalhos os itens a seguir:

Obter conhecimento terico e prtico sobre a tecnologia Internet embarcada; Adquirir conhecimentos sobre sistemas embarcados e microcontroladores, e sua respectiva conexo em rede; Projetar um sistema de monitoramento de temperatura para a sala de servidores do PoP-RN, que seja robusto e de baixo custo; Projetar um hardware microcontrolado com sensor de temperatura, interface de rede e controlador Ethernet, para obteno de dados de temperatura e sua respectiva disseminao na Internet; Especificar formalmente e implementar um software para aquisio remota de temperatura via Internet; Especificar formalmente e iniciar implementao de um sistema de informao WEB para gerar estatsticas, relatrios e grficos relacionados ao comportamento da temperatura, possibilitando o monitoramento remoto e em tempo real desse parmetro.

1.4. METODOLOGIA
Inicialmente foi feito um estudo sobre a Internet embarcada e as possveis arquiteturas e componentes que do suporte a essa tecnologia. Neste momento foi escolhida a soluo para Internet embarcada da Microchip, que baseada em microcontroladores PIC, processadores digitais de sinais DsPIC e no controlador Ethernet ENC28J60. Em seguida, foi realizado um estudo terico e prtico sobre microcontroladores envolvendo sua programao e interfaceamento com perifricos, como sensor de temperatura, display LCD, dentre outros. Posteriormente, foi estudado o simulador de circuitos microcontrolados Proteus VSM, onde os circuitos microcontrolados e respectivos software propostos foram simulados e validados. Basicamente, o projeto do hardware foi divido em dois circuitos: circuito microcontrolado para monitoramento de temperatura e circuito microcontrolado para conexo em rede Ethernet. Em seguida, foi realizado um estudo sobre programao concorrente e distribuda para a implementao do daemon para aquisio remota de temperatura. Este software se faz necessrio, quando o circuito utilizando como um sistema de aquisio e disponibilizao de dados de temperatura via Internet. O daemon o responsvel por receber os dados de temperatura, armazenar no banco de dados e em arquivo de LOG e notificar a ocorrncia de um alarme via e-mail. Posteriormente, foi estudada a tecnologia Java para WEB e seus conjuntos de framework para gerao de grficos, relatrios e armazenamento de informao em banco de dados. Essas tecnologias foram utilizadas para iniciar o processo de implementao do sistema de informao, que responsvel por permitir o monitoramento de temperatura atravs da WEB.

1.5. ESTRUTURA
No captulo 2 apresentada a tecnologia Internet embarcada, bem como algumas solues de hardware existentes no mercado. No captulo 3 so apresentados os componentes de hardware especificados para utilizao no presente trabalho. No captulo 4 apresentado o projeto dos circuitos para monitoramento de temperatura e para disponibilizao dos dados via Internet. No captulo 5 apresentada a metodologia, consideraes tericas e especificao formal em UML relativas ao daemon para aquisio remota de temperatura via Internet. No captulo 6 apresentada a metodologia, consideraes tericas e especificao formal em UML relativas ao sistema WEB. Por fim, no captulo 7 so feitas breves consideraes sobre alguns parmetros de desempenho em rede, avaliados em simulao, do circuito microcontrolado para monitoramento de temperatura e disponibilizao dos dados via Internet.

2. INTERNET EMBARCADA
Neste captulo feita uma breve apresentao da tecnologia Internet embarcada, suas aplicaes e algumas plataformas de hardware para desenvolvimento de projetos utilizando a Internet embarcada.

2.1. INTRODUO
A Internet embarcada nada mais do que uma tecnologia que permite a conexo de sistemas embarcados Internet, especialmente microcontroladores e DPS (Processadores Digitais de Sinais). Geralmente, isso feito atravs da implementao de pilhas de comunicao, neste caso TCP/IP, nos dispositivos embarcados. Para que um sistema embarcado possa conectar-se Internet, o mesmo deve possuir os seguintes componentes: Interface de rede; Controlador Ethernet; Pilha TCP/IP para sistemas embarcados;

A interface de rede necessria para realizar a conexo fsica do sistema embarcado com um segmento de rede. O controlador Ethernet o responsvel por codificar, no padro Ethernet, as informaes recebidas/enviados do microcontrolador ou DSP. J a pilha TCP/IP utilizada para ser embarcada (gravada) na memria no-voltil (Flash) do microcontrolador, a fim de estabelecer a conexo lgica com uma mquina remota em um determinado segmento de rede.

2.2. APLICAES
A Internet embarcada muito utilizada para possibilitar o monitoramento e acionamento remoto (WOOD, 2007A), (WOOD, 2007B) e (WOOD, 2007C). Por exemplo, perfeitamente possvel se construir um hardware utilizando Internet embarcada, que conectado a um segmento de rede e possui um conjunto de pginas HTML, que permitem que dispositivos conectados ao mesmo sejam controlados (habilitados ou desabilitados) remotamente e em tempo-real. Para efetuar esse controle, o usurio necessitaria apenas de conexo com a Internet e de um navegador WEB, para acessar as pginas HTML armazenadas no hardware. Outra possibilidade utilizar o hardware para fazer monitoramento remoto, ou seja, o mesmo obtm informaes de um ambiente e disponibiliza as mesmas via Internet. O presente trabalho est inserido nesse ltimo contexto de aplicao. Antigamente, para se fazer monitoramento ou acionamento remoto, utilizava-se um computador e uma placa de aquisio de dados. Esse modelo pode ser visto na Figura 2.1. Atravs do mesmo possvel realizar acionamento/monitoramento, tanto no interior de uma rede local quanto na Internet. 5

Figura 2.1 - Infra-estrutura tradicional para um sistema de acionamento ou monitoramento via WEB.

No modelo convencional utilizada uma placa especfica que se comunica com o computador, atravs de uma interface RS-232 ou USB, por exemplo. O servidor dedicado possui um servidor WEB, pginas HTML, o driver para comunicao com a placa e o programa de aplicao do usurio para fazer o monitoramento ou acionamento. Nesse modelo, o servidor WEB utilizado para publicar as pginas HTML na Internet. As pginas HTML so utilizadas como interface para o usurio interagir com a placa, enquanto o programa de aplicao responsvel por identificar que ao o usurio executou na pgina e realizar o respectivo tratamento, que envolve a utilizao do driver para estabelecer a comunicao e realizar na placa a ao solicitada pelo usurio. Quando se utiliza Internet embarcada para fazer monitoramento ou acionamento, o modelo radicalmente modificado e o servidor dedicado no mais necessrio. Basicamente, se substitui um computador por uma placa. Esse modelo pode ser visto na Figura 2.2. No modelo da Figura 2.2, o servidor WEB, as pginas HTML e o programa de aplicao esto armazenados na prpria placa e o driver de comunicao com o computador, naturalmente, no mais necessrio. Esse modelo possibilita que monitoramento e acionamento possam ser realizados a partir de uma rede local ou da Internet, utilizando um dispositivo dedicado e de baixo custo.

Figura 2.2 - Infra-estrutura proposta pela Internet embarcada para um sistema de acionamento ou monitoramento via WEB.

2.3. PLATAFORMAS EXISTENTES PARA INTERNET EMBARCADA

Essa seo apresenta algumas plataformas de hardware existentes no mercado com suporte tecnologia Internet embarcada.

2.3.1. PICDEM.NET 2
uma placa de desenvolvimento para solues Internet/Ethernet, fabricada pela Microchip (MICROCHIP, 2008A). A mesma possui o controlador Ethernet ENC28J60 (SMITH, 2005), (MICROCHIP, 2008B) e o microcontrolador Ethernet PIC18F97J60, que utiliza um controlador Ethernet como um de seus blocos internos. Essa plataforma ideal para utilizao com a pilha TCP/IP para microcontroladores e DSPs da Microchip, j que tanto a pilha quanto a plataforma so produzidos pela mesma empresa, minimizando assim problemas de incompatibilidade. Algumas caractersticas dessa placa so: Servidor WEB com suporte a HTML; Total suporte pilha TCP/IP da Microchip; Duas interfaces Ethernet (conector RJ-45); Conector para circuitos de expanso; Display alfa-numrico de 16x2 caracteres; Conector para programao e depurao no circuito (in circuit); Botes e LEDs programveis; Sensor de temperatura; Interface RS-232/RS-485; Relgio de tempo real;

O valor dessa placa est em torno de R$ 1.200,00. A placa PICDEM.net 2 (MICROCHIP, 2007) pode ser vista na Figura 2.3.

Figura 2.3 - Placa Microchip PICDEM.net 2.

2.3.2. EXPLORER16 BR PIC24FJ128GA010-I/PT

uma plataforma para desenvolvimento de solues Internet/Ethernet, fabricada pela empresa brasileira Labtools (LABTOOLS, 2008A) e licenciada como ferramenta Microchip. A mesma utiliza o controlador Ethernet ENC28J60 e o microcontrolador PIC24FJ128GA010I/PT. Esse microcontrolador pertence famlia PIC 24F, que so caracterizados por serem de 16 bits e possurem alto poder de processamento. Algumas das caractersticas dessa placa so: Microcontrolador PIC24FJ128GA010 da Microchip; Teclas e LEDs (4 teclas e 8 LEDs); Memria serial EEPROM 24WC256 (protocolo I2C); Memria serial EEPROM 25LC256 (protocolo SPI); Sensor de temperatura MCP9700 (sada analgica); Comunicao serial RS232; Comunicao CAN; Comunicao Ethernet; Boto de reset manual; Possibilidade de trabalhar com LCD 16x2 (alfanumrico) e LCD 128 x 64 (grfico). OBS.: LCDs no inclusos; Compatvel com os gravadores ICD2BR, ICD2 Microchip, PICkit e Real ICE Microchip.

O valor dessa placa est em torno de R$ 450,00. A placa Explorer16BR (LABTOOLS,

2008B) pode ser vista na Figura 2.4.

Figura 2.4 - Placa Labtools Explorer16BR.

2.3.3. MAGICPIC BOARD

uma plataforma para desenvolvimento de solues Ethernet/Internet e USB 2.0 fabricada pela empresa brasileira Microgenius (MICROGENIUS, 2008A). A plataforma utiliza o PIC 18F4550, que possui bloco interno para comunicao USB 2.0 e o controlador Ethernet ENC28J60. Algumas das caractersticas dessa placa so: Controle de displays LCD alfanumrico 16X2 (16 colunas por 2 linhas ) no modo 4 bits; 4 teclas de acesso direto; 4 leds para controle lgico visual; 2 rels NA/NF para acionamento de cargas externas de 10A / 220V; Canal USB 2.0 para comunicao USB (necessrio usar PIC18F4550); Espao fsico para soldar memria serial E2PROM 25c512; 1 trimpot para simulao e programao do canal A/D do PIC Microcontrolador PIC18F4550 DIP com 32Kbyte de Flash; Canal de gravao ICSP: Conector para modo depurao; Regulador de tenso; Controlador Ethernet ENC28J60; Entrada para Carto SD CARD.

O valor desta placa est em torno de R$ 390,00. A placa MagicPic board

(MICROGENIUS, 2008B) pode ser vista na Figura 2.5.

Figura 2.5 - Placa Microgenius MagicPic board.

2.3.4. DSPIC SIGMA 128

uma plataforma fabricada pela empresa brasileira Exsto (EXSTO, 2009A) para processamento de sinais, que possui capacidade de conexo Ethernet/Internet. Utiliza o DSP dsPIC33FJ128GP706 da Microchip e o controlador Ethernet ENC28J60. Algumas das caractersticas dessa placa so:

Utiliza o DSP dsPIC33FJ128GP706 da Microchip; Memria Flash de 8 Mega bits; 08 Leds de uso geral; 03 Chaves pulsativas; 03 Chaves Dip-Switch; 01 Boto de Reset; 02 Sadas de PWM; 04 Entradas analgica; Sadas para display alfanumrico e grfico; 01 Interface serial; 01 controlador Ethernet baseado no ENC28J60; Codificador e Decodificador de udio; Conectores de expanso.

O valor desta placa est em torno de R$600,00. A placa Exsto DsPIC Sigma 128 (EXSTO, 2009B) pode ser vista na Figura 2.6.

Figura 2.6 - Placa Exsto DsPIC Sigma 128.

10

3. COMPONENTES DE HARDWARE
Este captulo descreve os principais componentes eletrnicos utilizados no hardware do projeto. Inicialmente feita uma breve descrio sobre os microcontroladores da famlia PIC 18 F. Em seguida, so descritos os microcontroladores PIC18F2620 e PIC18F4620, que foram os microcontroladores utilizados at o momento para montagem do circuito de monitoramento de temperatura e simulao dos circuitos com conexo em rede Ethernet. So feitas consideraes sobre esses microcontroladores em relao a recursos, capacidade de memria, perifricos, caractersticas eltricas, recursos especiais da CPU, arquitetura interna, pinagem, organizao da memria, ciclos de mquina e configurao de oscilao. Alm disso, so apresentados, de forma breve, os perifricos do microcontrolador utilizados no projeto: E/S digital, conversor A/D (Analgico/Digital), Timer e Mdulo MSSP (Master Synchronous Serial Port) no modo SPI (Serial Peripheral Interface). Outros componentes importantes utilizados no projeto tambm so descritos, como o sensor de temperatura LM35, o display LCD JHD204, o controlador Ethernet ENC28J60 e a interface de rede 100/10 Base-TX.

3.1. MICROCONTROLADOR
Os Microcontroladores utilizados so fabricados pela Microchip (MICROCHIP, 2008A) e pertencem famlia PIC 18. Os microcontroladores dessa famlia so ideais para aplicaes que necessitam de processamento a 10-16 MIPS (Milhes de Instrues por Segundo). Os mesmos possuem at 128KB de memria de programa e uma faixa de 18-100 pinos. Alm disso, so otimizados para executar cdigos gerados por compiladores da linguagem C (especialmente o C18 da Microchip), possuem 16 bits de palavra de programa e um conjunto de perifricos, tais como: E/S digitais, PWM (Pulse Width Modulation), USART (Universal Synchronous Receiver Trasmitter), entradas analgicas, MSSP (Master Synchronous Serial Port), dentre outros. A famlia PIC 18 tambm permite a implementao em firmware de tecnologias como USB, ZigBee, Ethernet e CAN e/ou utilizao, em conjunto, de um microcontrolador PIC 18 com chips externos que implementam essas tecnologias. Para a utilizao no hardware do projeto foram selecionados trs microcontroladores da famlia PIC 18: 18F2620, 18F4620 e 18F4685. Na seo a seguir so descritas as principais caractersticas do PIC 18F2620 e 18F4620 (MICROCHIP, 2008C), que foram os microcontroladores utilizados at o momento para montagem do circuito de monitoramento de temperatura e para a elaborao de simulaes de circuitos com conexo Ethernet.

11

3.1.1. CARACTERSTICAS
Os microcontroladores PIC 18F2620 e PIC 18F4620 apresentam caractersticas muito parecidas. Mas o PIC 18F4620 mais adequado, quando a quantidade de interfaces E/S do 18F2620 no suficiente para uma determinada aplicao. Alm disso, como so microcontroladores muito similares, o uso dos mesmos pode ser intercambivel. As principais caractersticas desses microcontroladores so: Memria de programa Flash com 64K Bytes; Memria EEPROM de 1024 bytes; Memria SRAM de 3986; Multiplicao por hardware; Processamento a 10 MIPS; Mais de 19 fontes de interrupo; Oscilador RC Interno; Interrupes com prioridade; USART; MSSP (modo SPI e I2C); Conversor A/D (Analgico/Digital); 4 Temporizadores; E/S Digital; Uma das principais vantagens desses microcontroladores consiste no tamanho de sua memria de programa. Na prtica, significa que o programa que ser gravado no microcontrolador pode ter at 64KB. Os microcontroladores mais populares, por exemplo, possuem entre 1KB e 8KB de memria de programa. Alm disso, os mesmos possuem uma quantidade significativa de memria voltil (SRAM) e nesta memria que os resultados temporrios de clculos ou leituras de E/S so armazenados. Esses microcontroladores tambm implementam uma memria no voltil do tipo EEPROM de 1024 bytes, possibilitando assim que alguns dados possam ser recuperados, mesmo aps um desligamento do circuito onde o microcontrolador est inserido. Na Tabela 3.1 podem ser verificadas algumas caractersticas desses microcontroladores em relao aos tipos de memria utilizadas internamente. Pode-se perceber que em relao capacidade de memria o PIC18F2620 e PIC18F4620 so idnticos.

12

Tabela 3.1 - Capacidade de memria dos microcontroladores PIC18F2620 e PIC18F4620.

Microcontrolador

Memria de Programa Flash (bytes) Instrues (em words)

Memria de Dados SRAM (bytes) EEPROM (bytes)

PIC18F2620 PIC18F4620

64K 64K

32768 32768

3986 3986

1024 1024

Na Tabela 3.2 podem ser verificadas algumas caractersticas desses microcontroladores em relao disponibilidade de perifricos. Percebe-se que o PIC18F4620 possui mais E/S, canais de converso A/D e possui um mdulo ECCP (Enhanced Capture/Compare/PWM) e outro CCP (Capture/Compare/PWM). Ambos microcontroladores podem suportar SPI (Serial Peripheral Interface) e I2C (Inter-Intergrated Circuit) no mdulo MSSP.

Tabela 3.2 - Perifricos dos microcontroladores PIC18F2620 e PIC18F4620. Microcontrolador I/O 10-bit A/D (ch) CCP/ECCP (PWM) MSSP SPI I2C EUSART Timers 8/16-bits

PIC18F2620 PIC18F4620

25 36

10 13

2/0 1/1

Sim Sim

Sim Sim

1 1

1/3 1/3

Esses microcontroladores possuem tambm alguns recursos especiais relacionados CPU (Unidade Central de Processamento). So eles: Power-on Reset (POR): faz com que o microcontrolador ao ser ligado seja mantido em estado de reset, at que a tenso VDD (tenso de alimentao do circuito) atinja um nvel mnimo aceitvel para operao; Brown-out Detect (BOD): faz com que o microcontrolador seja resetado, se a tenso de alimentao VDD cair abaixo de um determinado nvel que pode ser configurado via programa; Power-up Timer (PWRT): causa um delay de aproximadamente 65.6 ms, que mantm o microcontrolador em estado de reset aps o mesmo ser ligado ou ter ocorrido um reset causado por um evento de Brown-Out. Pode ser habilitado ou desabilitado por programa;

13

Oscilator Start-up Timer (OST): gera um delay de 1024 ciclos do oscilador logo aps o trmino do delay do PWRT, a fim de assegurar que o oscilador tenha sido inicializado corretamente e esteja estvel, antes do microcontrolador sair do estado de reset; Watchdog timer (WDT): um recurso que pode ser muito til para garantir restries de tempo e prevenir o travamento do microcontrolador na execuo de determinada tarefa. Consiste em um timer progressivo que resetar o microcontrolador, cada vez que estourar seu limite mximo. Logo, em uma operao normal, o microcontrolador deve zerar esse timer periodicamente, para no ocorrer o estouro. Se o watchdog no for zerado, significa que o microcontrolador travou e o sistema dever ser resetado para poder entrar em funcionamento novamente; Fail-Safe Clock Monitor: permite ao microcontrolador continuar em operao, mesmo na ocorrncia de uma falha no oscilador externo, o que ocasiona automaticamente a mudana da configurao de oscilao de forma a utilizar o oscilador interno.

3.1.2. ARQUITETURA INTERNA

Como pode ser observado na Figura 3.1 (MICROCHIP, 2008C), estes microcontroladores utilizam arquitetura Harvard, j que possuem dois barramentos, um para dados e outro para programa. Alm disso, como o barramento entre a CPU e a memria de dados de 8 bits, logo podemos defini-los como microcontroladores de 8 bits. Esses microcontroladores utilizam arquitetura RISC (Reduced Instruction Set Computer), ou seja, possuem um conjunto simples e pequeno de instrues, que levam aproximadamente a mesma quantidade de tempo para serem executadas. Na seo anterior foi informado que os microcontroladores possuam 64KB de memria de programa. Na verdade, observando a Figura 3.1, percebe-se que o barramento de programa de 16 bits, logo a quantidade real de memria de programa seria de 32KW, j que a organizao da mesma em words (16 bits) e no em bytes (8 bits). Na Figura 3.1 so selecionados alguns subitens importantes da arquitetura interna e so feitas as consideraes a seguir: 1. As vias de comunicao do microcontrolador com possveis perifricos externos esto ligadas ao barramento de dados. Dessa forma, possvel, por exemplo, ler o valor de um sensor ou acionar uma sada atravs de um programa armazenado na memria de programa do microcontrolador; 2. Os perifricos do microcontrolador (memria EEPROM, Timers, MSSP, CCP, dentre outros) esto tambm ligados ao barramento de dados e compartilham recursos do microcontrolador entre si. Dessa forma, alguns perifricos s podem ser utilizados em detrimento de outros; 14

3. O barramento de instrues de 16 bits, sendo dessa forma, uma palavra de 16 bits (word) a unidade de armazenamento da memria de programa e no bytes. atravs deste barramento que lido o programa armazenado no microcontrolador; 4. O barramento de dados de 8 bits, dessa forma a ULA (Unidade Lgica Aritmtica) e o microcontrolador so caracterizados por operarem sobre 8 bits. Alm disso, a maior varivel de um programa armazenado no microcontrolador pode ser apenas de 8 bits;

5. Existem 21 vias para enderear a memria de programa Flash do microcontrolador. Como 2 igual a 2M bytes ou 1M word, essa a quantidade mxima possvel de memria de programa nesta arquitetura; 6. Os microcontroladores possuem uma pilha de 31 nveis, que um recurso utilizado na chamada de procedimentos. A quantidade de nveis implica na quantidade de procedimentos que um programa pode fazer em cascata. Em geral, programas muito complexos so formados por um conjunto de procedimentos que podem ser chamados em cascata. Dessa forma, ter uma quantidade elevada de nveis permite que se tenha flexibilidade na diviso de um programa complexo em pequenas tarefas; 7. Estes microcontroladores podem possuir at 4KB de memria de dados RAM, pois existem 12 vias que permitem enderear este espao de memria. Os 4KB so justificveis j que 2 igual 4096; Alm dos subitens comentados acima, outras caractersticas importantes podem ser observadas na Figura 3.1, como uma unidade dedicada a multiplicao por hardware e alguns recursos como Watchdog Timer, Power-on Reset, Brown-out Reset, dentre outros.

15

Figura 3.1 - Arquitetura interna do PIC 18F2620/18F4620.

16

3.1.3. PINAGEM
Os microcontroladores PIC18F2620 e PIC18F4620 possuem 25 e 36 pinos de E/S, respectivamente. Se um pino de E/S significa que o mesmo pode ser configurado e utilizado para atuar tanto como sada como quanto entrada de dados. Os pinos de E/S dos microcontroladores PIC18F2620 e PIC18F4620 esto divididos em 4 e 5 grupos respectivamente, denominados PORTs (portas). Estes PORTs so chamados de PORTA, PORTB, PORTC, PORTD e PORTE. Apenas o PIC18F4620 possui o PORTE. As pinagens do PIC18F2620 e PIC18F4620 podem ser vistas nas Figuras 3.2 e 3.3 (MICROCHIP, 2008C), respectivamente. Um pino especfico de um PORT referenciado com a inicial RX, onde X pode ser A, B, C, D ou E (referente ao PORT que este pino faz parte) acrescida de um nmero de 0 a 7. Dessa forma, RA7, RC5 e RB2 so exemplos de nomes de pinos nos microcontroladores em questo. Em geral, nos microcontroladores PIC, alm da funo bsica de E/S um pino pode ter funes mais avanadas, como por exemplo, uma sada PWM ou um canal de leitura A/D. Estas funes adicionais, quando configuradas, fazem com que os pinos em questo percam a funo bsica de E/S e passem a operar na funo especial configurada para o mesmo. Por exemplo, o pino 3 dos microcontroladores cujo nome RA1/AN1, alm de possuir a funo bsica de E/S, tambm pode ser uma entrada analgica. Em geral, esse mesmo conceito se aplica aos demais pinos dos microcontroladores PIC, variando apenas a funcionalidade especial associada a cada pino bsico de E/S.

Figura 3.2 - Pinagem do microcontrolador PIC18F2620.

17

Figura 3.3 - Pinagem do microcontrolador PIC18F4620.

3.1.4. CARACTERSTICAS ELTRICAS

Algumas caractersticas eltricas destes microcontroladores podem ser verificadas na Tabela 3.3.
Tabela 3.3 - Caractersticas eltricas dos microcontroladores PIC18F2620 e PIC18F4620.

Caractersticas Tenso de operao Voltagem em qualquer pino com exceo de VDD e MCLR Voltagem do MCLR em relao a Vss Voltagem do VDD em relao a Vss Dissipao total de energia Corrente mxima por pino Corrente mxima de todos PORTs Freqncia mxima de operao Temperatura de operao

Faixa de Operao 2.0 V at 5.5 V - 0.3V at (Vdd + 0.3V) 0 V at +13.25V - 0.3V at +7.5V 1.0 W 25 mA 200 mA 40 MHz -40C at + 125C

18

3.1.5. CICLOS DE MQUINA

Para que esses microcontroladores possam executar um ciclo de mquina, so necessrios 4 pulsos de clock da fonte de oscilao do sistema, j que internamente o microcontrolador possui um pipeline de 4 estgios. O ciclo de mquina o tempo necessrio para que o microcontrolador possa executar uma nica instruo. Em geral, nos microcontroladores da famlia PIC, o clock interno equivalente ao clock externo divido por 4, devido o pipeline utilizado conforme mencionado anteriormente. Logo, por exemplo, se for utilizado um cristal de 4 MHz, os microcontroladores estaro operando internamente na freqncia de 1 MHz (ou 1 MIPS). Entretanto, mais importante que a freqncia interna o perodo dessa freqncia (o inverso da mesma), que equivalente ao tempo de durao de um ciclo de mquina. Logo, para um clock externo de 4 MHz, o ciclo de mquina ser 1s. Considere uma nova configurao: supondo um cristal de 20 MHz, o microcontrolador operar a 5 MHz (freqncia externa divida por 4) e a 5 MIPS e seu ciclo de mquina ser de 200 ns (inverso da freqncia). Percebe-se que, ao aumentar o clock externo, a velocidade de processamento MIPS tambm aumenta, logo so duas grandezas relacionadas e, em geral, diretamente proporcionais. Alm disso, foi visto na seo anterior que a freqncia mxima de operao desses microcontroladores de 40MHz, logo os mesmos podem operar a at 10 MIPS.

3.1.6. ORGANIZAO DA MEMRIA DE PROGRAMA

Conforme informado anteriormente, estes microcontroladores apresentam 64 KB ou 32 KW de memria de programa do tipo Flash. A organizao dessa memria pode ser vista na Figura 3.4. Como pode ser visto na Figura 3.4 (MICROCHIP, 2008C), o vetor de reset (Reset Vector) est posicionado no endereo hexadecimal 0x0000, que o endereo inicial utilizado pelo microcontrolador para execuo, quando o mesmo ligado ou reiniciado (resetado). Em seguida, pode ser observado o endereo 0x0008, que chamado de vetor de interrupo alta, e o endereo 0x0018 corresponde ao vetor de interrupo baixa. Atravs desses vetores de interrupo podem ser atribudas prioridades s interrupes utilizadas. Aps o vetor de interrupo baixa pode ser observado o inicio da memria de programa que termina no endereo 0xFFFF. nesta ltima regio de memria que o programa gravado no microcontrolador fica armazenado. A partir do endereo final da memria de programa se encontra uma regio de memria no implementada nestes microcontroladores, que identificada na Figura 3.4 pela regio escura com o termo Read 0. Alm disso, esses microcontroladores podem enderear at 2 Mbytes devido o contador de programa possuir 21 bits. O tipo de memria e esquema utilizados pelos microcontroladores PIC so muito adequados para o desenvolvimento de prottipos, pois a mesma regravvel at 100.000 vezes e apagada eletricamente. Alm disso, uma das grandes vantagens de utilizar um microcontrolador PIC como os da famlia 18 que eles permitem gravao de programa no modo In-Circuit. Na prtica isto significa que o microcontrolador pode ser gravado no prprio 19

circuito de prottipo, no sendo necessria a retirada do microcontrolador do circuito para grav-lo.

Figura 3.4 - Mapa da memria de programa e pilha dos microcontroladores PIC18F2620/PIC18F4620

3.1.7. ORGANIZAO DA MEMRIA DADOS

A memria dos microcontroladores PIC18F2620 e PIC18F4620 do tipo RAM (Random Access Memory) esttica (SRAM) e divida em dois grupos: SFR (Special Function Register ou Registrador de Funo Especial) e GPR (General Purpose Register ou Registrador de Propsito Geral). Os registradores do tipo SFR so utilizados para que o usurio altere configuraes do microcontrolador em relao aos seus perifricos (timer, conversor A/D, PWM). Em geral, essa mudana feita atravs da escrita de valores binrios nesses registradores, assim o microcontrolador automaticamente l esses registros e passa a operar da maneira desejada. J os registradores do tipo GPR so utilizados para armazenar valores temporrios relativos ao programa armazenado no microcontrolador, como por exemplo, o resultado de clculos. Esse espao possui tamanho de 3968 bytes. Na Figura 3.5 (MICROCHIP, 2008C) pode ser vista a memria de dados desses microcontroladores. A mesma composta por 16 bancos com 256 bytes cada. Os 15 primeiros bancos de memria so do grupo GPR e o ltimo banco destinado ao SFR. Os registradores que fazem parte do grupo SFR podem ser visualizados na Figura 3.6. Alm disso, esses microcontroladores dispem de 1024 bytes de memria no-voltil que esto organizados do endereo 0x0000 a 0x03FF. 20

Figura 3.5 - Memria de dados dos microcontroladores PIC18F2620/PIC18F4620.

21

Figura 3.6 - Registradores de Funo Especial (SFR) dos microcontroladores PIC18F2620/PIC18F4620.

3.1.8. CONFIGURAES DO OSCILADOR

Os microcontroladores PIC18F2620 e PIC184620 podem utilizar 10 configuraes de oscilao distintas. Entretanto, neste documento abordada apenas a configurao oscilador a cristal ou ressonador cermico, que foi a configurao utilizada na montagem do circuito de monitoramento de temperatura e nas simulaes dos circuitos com conexo Ethernet. Nos modos de oscilao LP (Low Power), XT (XTAL) e HS (High Speed), um cristal ou ressonador cermico conectado nos pinos OSC1 e OSC2 dos microcontroladores, para estabelecer a oscilao, como pode ser visto na Figura 3.7 (MICROCHIP, 2008C). H dois capacitores ligados em paralelo com o terra junto ao cristal. A funo deles garantir a estabilidade da fonte de oscilao. A principal diferena entre os modos LP, XT e HS est na freqncia do cristal. Se a mesma estiver abaixo de 1 MHz o modo selecionado deve ser o LP, se estiver entre 1 MHz e 4 MHz, o modo selecionado deve ser o XT e, se for maior que 4 MHz, o modo selecionado deve ser o HS. Na Tabela 3.4 pode ser observada uma relao entre a freqncia do cristal, modo de oscilao e os capacitores necessrios.

22

Figura 3.7 - Conexo entre o cristal e o microcontrolador na configurao "Oscilador a Cristal".

Tabela 3.4 - Relao entre o modo de oscilao, a freqncia do cristal e os capacitores necessrios.

Tipo de Oscilador LP XT

Freqncia do Cristal 32KHz 1 MHz 4 MHz 4 MHz 10 MHz

Valores testados C1 30pF 15pF 15pF 15pF 15pF 15pF 15pF

de

capacitores C2 30pF 15pF 15pF 15pF 15pF 15pF 15pF

HS

20 MHz 25 MHz

3.1.9. PERIFRICOS
Nesta seo so feitas breves descries dos perifricos utilizados pelos microcontroladores no desenvolvimento do projeto, seja para o monitoramento de temperatura ou para possibilitar a conexo Ethernet.

23

3.1.9.1. E/S DIGITAL

Dependendo do microcontrolador selecionado (PIC18F2620 ou PIC18F4620), h 4 ou 5 grupos de E/S digitais, que a Microchip chama de ports, como foi visto na seo 3.1.3. Alguns pinos de E/S so multiplexados com funcionalidades alternativas providas por diversos perifricos integrados ao microcontrolador. Em geral, quando um perifrico est habilitado, o pino corresponde no pode ser utilizado para E/S de propsito geral. Cada port possui trs registradores associados sua operao. So eles: Registrador TRIS (define o sentido do fluxo de dados Entrada ou Sada); Registrador PORT (l o nvel do pino do microcontrolador); Registrador LAT (latch de sada). O Data LatchA (registrador LATA) utilizado em operaes do tipo leituramodificao-escrita nos valores dos pinos de E/S do PORTA. Um modelo simplificado de um port genrico, sem interfaces de outros perifricos, pode ser visto na Figura 3.8 (MICROCHIP, 2008C). O PORTA um port bidirecional de largura de 8 bits. A direo (entrada ou sada) do mesmo definida pelo registrador TRISA. Ao atribuir o valor lgico 1 a um bit do TRISA o pino correspondente do PORTA opera como entrada, ficando este pino no modo de altaimpedncia. Ao atribuir o valor 0 a um bit do TRISA faz com que o pino correspondente opere como sada, armazenado um valor no latch de sada do pino selecionado.

Figura 3.8 - Modelo genrico de PORT dos microcontroladores PIC18F2620 e PIC18F4620

24

Ao ler o PORTA, o que se l so os status dos pinos e ao se escrever no PORTA realizada na verdade uma escrita no latch dos pinos selecionados. O registrador Data LatchA (LATA) tambm mapeado na memria. Operaes do tipo leitura-modificaoescrita no registrador LATA so leituras e escritas no valor armazenado no latch de sada do PORTA.

3.1.9.2. TIMER 0
O Timer 0 um mdulo que permite fazer temporizaes e contagens no microcontrolador. Sua operao definida via software, podendo atuar como contador ou timer em modo 8 ou 16 bits. Alm disso, o mesmo pode operar a partir de uma fonte interna ou externa de clock. O registrador T0CON (ver Figura 3.6) controla todos os aspectos de operao do mdulo, incluindo a seleo de prescaler (recurso que permite contagem alm do limite do registrador TMR0). Um simplificado diagrama de blocos do Timer 0 no modo 8 bits pode ser visto na Figura 3.9 (MICROCHIP, 2008C) e de 16 bits na Figura 3.10 (MICROCHIP, 2008C).

Figura 3.9 - Diagrama de blocos do Timer 0 operando no modo 8 bits.

Figura 3.10 - Diagrama de blocos do Timer 0 operando no modo 16 bits.

25

O que define se o Timer 0 vai operar como contador ou temporizador o bit T0CS, que corresponde ao quinto bit do registrador T0CON. Quando T0CS for igual a 0, o Timer0 incrementado por padro a cada pulso de clock, exceto se um valor diferente de prescaler for selecionado. Se ocorre alguma escrita diretamente no registrador TMR0 (registrador de contagem), o processo de incremento inibido por dois ciclos de instruo. Mas o usurio pode escrever no TMR0 a fim de ajust-lo, levando em considerao os dois ciclos perdidos. O modo contador do Timer 0 selecionado atravs da atribuio do valor 1 ao bit T0CS. Nesse modo, o Timer0 incrementado a cada borda de subida ou descida do sinal presente no pino RA4/T0CKI. A configurao do processo de incremento baseado na borda do sinal feita pelo bit T0SE, que o quarto bit do registrador T0CON. Se esse bit for resetado o incremento ser feito pela borda de subida.

3.1.9.3. CONVERSOR A/D

O mdulo conversor Analgico-Digital (A/D) possui dez entradas no PIC18F2620 e treze entradas no PIC18F4620. Esse mdulo permite a converso de um sinal de entrada analgico em um digital de dez bits. Fazem parte do mdulo os cinco registradores a seguir: Registrador de resultado da parte alta da converso A/D: ADRESH; Registrador de resultado da parte baixa da converso A/D: ADRESL; Registrador 0 de controle A/D: ADCON0; Registrador 1 de controle A/D: ADCON1; Registrador 2 de controle A/D: ADCON2. O registrador ADCON0 controla a operao do conversor A/D, como por exemplo, o canal utilizado, o status da converso, a habilitao do conversor, dentre outros. O registrador ADCON1 configura os pinos do port para a utilizao com mdulo A/D e a voltagem de referncia utilizada pelo conversor. J ADCON2 configura o formato do resultado (justificado a esquerda ou direita), tempo de aquisio e a freqncia (clock) da converso. As tenses analgicas de referncia utilizadas pelo microcontrolador podem ser internas (pinos de alimentao VDD e VSS) ou externas atravs dos pinos RA3/AN3/VREF+ e RA2/AN2/VREF-/CVREF. Alm disso, esses microcontroladores possuem uma caracterstica interessante, que capacidade do conversor A/D operar mesmo quando o microcontrolador est em modo sleep (economia de energia). Para que o conversor continue operando quando em modo sleep, o clock de converso A/D deve ser gerado pelo oscilador RC interno do microcontrolador. A sada de um circuito sample-and-hold utilizada como entrada para o conversor, que gera o resultado baseando-se na tcnica de converso aproximaes sucessivas. Um reset no microcontrolador fora todos os registradores para o estado de reset, inclusive os registradores de controle do conversor A/D. Conseqentemente, o conversor A/D forado a se desligar e qualquer converso em curso abortada. 26

Cada pino de port associado ao conversor A/D pode ser configurado como entrada analgica ou digital. Os registradores ADRESH e ADRESL armazenam o resultado da converso. Quando o conversor A/D conclui o processo de converso, o resultado carregado no par de registradores ADRESH:ADRESL, o bit GO/DONE do registrador ADCON0 resetado e a flag de interrupo do conversor A/D (ADIF) setada. O digrama de blocos do mdulo conversor A/D pode ser visto na Figura 3.11 (MICROCHIP, 2008C).

Figura 3.11 - Diagrama de blocos do mdulo conversor A/D.

3.1.9.4. MDULO MSSP

O mdulo MSSP (Master Synchronous Serial Port) implementa uma interface serial utilizada para comunicao com outros dispositivos perifricos ou microcontroladores. Esses dispositivos perifricos podem ser EEPROMs seriais, registradores de deslocamento, controladores de display, conversores A/D, dentre outros. O mdulo MSSP pode operar em um dos dois modos a seguir: SPI (Serial Peripheral Interface); I2C (Inter-Intergrated Circuit); O mdulo MSSP possui trs registradores associados: SSPSAT (registrador de status), SSPCON1 e SSPCON2 (registradores de controle). O uso desses registradores e a configurao individual dos seus bits variam de forma significativa, dependendo do modo (SPI ou I2C) que o mdulo MSSP est operando. No modo SPI permitido a transmisso e recepo sncrona de dados de 8 bits simultaneamente. Todos os 4 modos SPI so suportados. Para realizar a comunicao SPI, tipicamente trs pinos so utilizados: 27

 Sada de dados serial (SDO) RC5/SDO; Entrada de dados serial (SDI) RC4/SDI/DAS; Clock serial (SCK) RC3/SCK/SCL. Quando no modo Slave do SPI, o pino adicional SS (Slave Select) RA5/AN4/SS/HLVDIN/C2OUT deve ser utilizado. Na Figura 3.12 (MICROCHIP, 2008C) pode ser visto o diagrama de bloco do MSSP quando operando no modo SPI.

Figura 3.12 - Diagrama de blocos do MSSP no modo SPI.

Quando o mdulo MSSP est operando no modo SPI, o mesmo possui quatro registradores associados. So eles: Registrador de controle 1 MSSP (SSPCON1); Registrador de status MSSP (SSPSTAT); Registrador buffer serial de transmisso/recepo (SSPBUF); Registrador de deslocamento MSSP (SSPSR) no acessvel diretamente; Os registradores SSPCON1 e SSPSTAT so utilizados no modo SPI para controle e status, respectivamente. O registrador SSPSR um registrador de deslocamento utilizado para o deslocamento dos dados de sada ou entrada. O SSPBUF um registrador buffer onde os bytes de dados so lidos e escritos. Em operaes de recepo, SSPSR e SSPBUF so 28

utilizados em conjunto a fim de criar um receptor double-buffer. Quando o SSPR recebe um byte completo, o mesmo transferido ao SSPBUF e a interrupo SSPIF setada. J durante a transmisso, o SSPBUF no est no formato double-buffer. Uma escrita em SSPBUF escrever em ambos registradores (SSPBUF e SSPSR). Resumindo, o mdulo MSSP consiste basicamente de registradores de deslocamento de transmisso/recepo (SSPSR) e de um registrador buffer (SSPBUF). O SSPSR desloca o dado para a sada ou entrada do microcontrolador a partir do bit mais significativo. O SSPBUF espera todos os dados serem escritos no SSPSR. Uma vez que os 8 bits do dado tenham sido recebidos, esse byte movido para o registrador SSPBUF. Ento, o bit BF (buffer cheio) do registrador SSPSTAT e o bit de flag de interrupo (SSPIF) setado. Quando o SSPBUF opera no modo double-buffer a recepo do prximo byte pode ser iniciada antes da leitura do dado que acabou de ser recebido. Qualquer escrita no registrador SSPBUF durante a transmisso/recepo de dados ser ignorada e o bit de coliso na escrita WCOL setado. O software do usurio deve resetar e monitorar o bit WCOL para poder determinar se a escrita no registrador SSPBUF foi realizada com sucesso. Quando o software de aplicao do usurio espera a recepo de um dado vlido, o SSPBUF deve ser lido antes que o prximo byte de dados a ser transferido seja escrito no SSPBUF. O bit de buffer cheio BF (bit 0 de SSPSTAT) indica quando o SSPBUF foi carregado com o dado recebido, ou seja, a transmisso est completa. Quando o SSPBUF lido, o bit BF resetado. Esse dado no relevante quando o SPI est operando apenas em modo de transmisso. Geralmente, a interrupo do mdulo MSSP utilizada para determinar quando uma transmisso/recepo foi concluda, ento o SSPBUF deve ser lido e/ou escrito. Se o mtodo da interrupo no utilizado, ento o software de aplicao pode fazer polling para garantir que uma coliso no ocorreu. A Figura 3.13 (MICROCHIP, 2008C) exibe uma comunicao entre interfaces SPI de dois microcontroladores. O controlador mestre inicia a transferncia de dados atravs do envio do sinal SCK. O dado deslocado em ambos registradores de deslocamento na borda programada (subida ou descida) do sinal de clock e armazenado em um latch na transio oposta da borda. Ambos microcontroladores devem ser programados para a mesma polaridade do clock (CKP) para que possam enviar e receber dados simultaneamente.

Figura 3.13 - Exemplo de comunicao entre microcontroladores utilizando interface SPI.

29

3.2. SENSOR DE TEMPERATURA

O LM35 um circuito-integrado sensor de temperatura, fabricado pela National Semiconductor (NATIONAL SEMICONDUCTOR, 1994), que gera uma tenso de sada linearmente proporcional temperatura em graus Celsius, a taxa de 10mV para cada 1C de temperatura. Alm disso, o LM35 apresenta vantagens em relao aos sensores de temperatura calibrados em Kelvin, j que no necessrio fazer a subtrao de uma constante a partir do sinal de sada do sensor, para que se obtenha a relao em graus Celsius. O LM35 no necessita de qualquer calibrao externa ou trimming, para fornecer com exatido valores de temperatura com variaes de 0,25C ou at 0,75C na faixa de temperatura de -55C a 150C. O sensor tambm possui sada com baixa impedncia, linear e calibrao precisa, fazendo com que o interfaceamento de leitura seja simples. Este sensor pode ser alimentado por uma fonte simples ou simtrica, dependendo de como se deseja o sinal de sada. Mas, independente da fonte utilizada, a sada continuar sendo de 10mV/C, sendo drenada uma corrente de 60A para a alimentao. A seguir apresenta-se um resumo das caractersticas do sensor: Calibrado diretamente em graus Celsius; Linear: +10.0 mV/C (fator de escala); 0,5C de exatido garantida (a 25C); Faixa de funcionamento de -55C a +150C; Adequado para aplicaes de monitoramento remoto; Baixo custo; Opera em tenses de 4 a 30 volts; Dreno de corrente menor que 60A; Sada com baixa impedncia: 0,1 por 1 mA. Na Figura 3.14 (NATIONAL SEMICONDUCTOR, 1994) pode ser visto o encapsulamento do LM 35 utilizado no projeto e na Figura 3.15 (NATIONAL SEMICONDUCTOR, 1994) pode ser vista a configurao utilizada. Nesta configurao, o sensor mede temperaturas de +2C a +150C.

Figura 3.14 - Encapsulamento do LM35 utilizado.

30

Figura 3.15 - Configurao em que o LM35 foi utilizado.

3.3. DISPLAY LCD

Existem no mercado diversos tipos de displays LCD alfanumricos que podem ser utilizados com microcontroladores. Em especial, os displays LCD com o controlador Hitachi HD44780 so os mais populares e consolidados no mercado, tornando-se um padro de fato. O controlador do display LCD utilizado no projeto o S6A0069 (SAMSUNG, 2000), que se mostrou equivalente ao Hitachi HD44780. O Display utilizando no projeto o JHD 204A. O mesmo possui 20 caracteres por 4 linhas, backlight (luz de fundo) azul, 8 bits de dados para comunicao (em paralelo) e necessita de uma fonte de alimentao simples para sua utilizao. O display LCD similar ao mostrado na Figura 3.16 (JHD204, 2005).

Figura 3.16 - Display LCD JHD204.

A funo associada e descrio dos pinos do Display LCD podem ser vistas na Tabela 3.5.

31

Tabela 3.5 - Pinagem do Display LCD JHD204.

Pino 1 2 3 4

Nome Vss Vcc Vee RS

Descrio Ground Alimentao do circuito Ajuste no contraste do LCD Instruo / Seleo registrador de dados Selao de leitura/escrita

Funo 0 V (GND) +5V

do RS = 0: registrador de instruo; RS = 1: registrador de dados; R/W = 0: registrador de escrita; R/W = 0: registrador de leitura;

R/W

6 7 8 9 10 11 12 13 14 15 16

E DB0 DB1 DB2 DB3 DB4 DB5 DB6 DB7 LED+ LED-

Sinal de habilitao

Entrada/ Sada de dados

8 bits: DB0 DB7

Voltagem para o LED+ Voltagem para o LED-

+5V 0V

32

3.4. CONTROLADOR ETHERNET

Basicamente, o objetivo principal de um controlador Ethernet receber uma informao e gerar como resultado um dado equivalente codificado no padro IEEE 802.3 (Ethernet). O controlador Ethernet utilizado no projeto o ENC28J60 (SMITH, 2005), (MICROCHIP, 2008B) da Microchip. O ENC28J60 um controlador Ethernet stand-alone, com o padro industrial SPI para comunicao serial com outros dispositivos. O ENC28J60 rene todas as especificaes IEEE 802.3 e incorpora um conjunto de esquemas de filtros de pacote para limitar a quantidade de pacotes que realmente necessitam ser processados. Alm disso, o mesmo possui um mdulo de DMA (Direct Memory Access) dedicado, para permitir uma maior vazo de dados e uma unidade de hardware dedicada para clculo do checksum, que uma informao para deteco de erro utilizada em diversos protocolos de rede. A comunicao com um controlador host, como por exemplo um microcontrolador, implementada via pino de interrupo e interface SPI, a uma velocidade superior a 20MHz. Dois leds so utilizados para indicar a atividade de rede. O diagrama de blocos simplificado desse controlador Ethernet pode ser visto na Figura 3.17 (MICROCHIP, 2008B).

Figura 3.17 - Diagrama de blocos simplificado do controlador Ethernet ENC28J60.

O ENC28J60 formado por sete blocos funcionais: 1. Uma interface SPI que permite a comunicao do controlador host, por exemplo um microcontrolador, com o ENC28J60; 2. Registradores de controle que so utilizados para controle e monitoramento do ENC28J60; 3. Dual Port RAM buffer para transmisso e recepo de pacotes de dados; 33

4. rbitro para controlar o acesso ao RAM buffer quando requisies so feitas a partir da DMA e dos blocos de transmisso e recepo; 5. Uma interface de barramento que interpreta dados e comandos recebidos via interface SPI; 6. Mdulo (ou camada) MAC (Medium Access Controller) que implementa o padro IEEE 802.3; 7. Camada fsica (PHY) que codifica e decodifica o dado analgico presente na interface de par tranado. Esse controlador Ethernet tambm suporta outros blocos, como oscilador, regulador de tenso on-chip, dentre outros. Um tpico circuito de aplicao do ENC28J60 pode ser visto na Figura 3.18 (MICROCHIP, 2008B). Alm do controlador, um transformador de pulso e alguns componentes passivos so necessrios para conectar um microcontrolador a uma rede Ethernet.

Figura 3.18 - Tpico circuito de aplicao do ENC28J60.

O esquema de oscilao utilizado foi baseado em cristal, atravs de um esquema similar ao discutido na seo 3.1.8, sendo que o cristal utilizado foi de 25MHz. Para estabelecer uma interface Ethernet de fato, o ENC28J60 necessita de um conjunto de componentes padronizados, que devem ser instalados externamente. Esses componentes devem ser conectados como na Figura 3.19 (MICROCHIP, 2008B).

Figura 3.19 - Componentes padronizados necessrios para estabelecer uma interface Ethernet.

34

Os circuitos analgicos internos do mdulo PHY necessitam de uma resistncia externa de 2.32 K, um resistor de 1% deve ser anexado do RBIAS referncia de terra. Esse resistor influencia na amplitude dos sinais TPOUT+/-. Dessa forma, esse resistor deve ser colocado o mais prximo possvel do controlador, mas afastado das trilhas da placa de circuito impresso, a fim de evitar rudo capacitivo, que certamente afetaria o sinal de transmisso. Alm disso, alguns dispositivos (ou componentes) de lgica digital internos ao controlador operam na tenso de 2.5 Volts. O prprio controlador possui um regulador de tenso interno para gerar essa voltagem. O nico componente externo necessrio um filtro capacitivo, conectado do Vcap referncia de terra. Um transformador de pulso do tipo 1:1 center-taped nos pinos TPIN+/TPIN- e TPOUT+/TPOUT necessrio para a operao Ethernet. O ENC28J60 foi desenvolvido para operar na tenso de 3.3 volts. De qualquer forma, ele pode facilmente ser integrado a um sistema (ou circuito) cuja tenso de alimentao seja 5 Volts. Os pinos da interface SPI CS, SCK, RESET e SI possuem tolerncia a 5 Volts. Por outro lado, se o controlador host (microcontrolador) est operando a 5 Volts e o ENC28J60 gera na sua interface SPI de comunicao com o microcontrolador um sinal CMOS de 3.3 Volts, o microcontrolador no interpretar o sinal como nvel alto correspondente especificao SPI. Logo, necessrio um transdutor de nvel unidirecional para elevar esse sinal a 5 Volts e enviar para a interface SPI do microcontrolador. Esse esquema pode ser visto na Figura 3.20 (MICROCHIP, 2008B). A pinagem do ENC28J60 pode ser vista na Figura 3.21 (MICROCHIP, 2008B).

Figura 3.20 - Esquema de comunicao entre microcontrolador e ENC28J60 utilizando transdutor de nvel unidirecional.

Figura 3.21 - Pinagem do controladdor Ethernet ENC28J60.

35

Circuitos integrados como 74HCT08 (quad AND), 74ACT125 (quad 3-state buffer) ou muitos outros chips CMOS de 5 Volts com entradas de nvel TTL bufferizadas podem ser utilizadas para fazer essa converso de nvel . Os 3-state so indicados principalmente para sistemas (ou circuitos) que compartilham o barramento SPI com outros dispositivos.

3.5. INTERFACE DE REDE

Como interface de rede foi utilizada uma interface de rede 100/10 Base-TX RJ45 com transformador isolador interno e compatvel com o padro 802.3 (Ethernet). A interface de rede similar vista na Figura 3.22.

Figura 3.22 - Interface de rede 100/10 Base-Tx RJ45.

36

4. DESENVOLVIMENTO DO SISTEMA MICROCONTROLADO

Esse captulo descreve o processo de desenvolvimento do hardware e software. O captulo divido em duas partes: projeto de hardware e de software. Na seo projeto de hardware apresentada a metodologia utilizada e so descritas algumas decises de projeto importantes. Em seguida, so apresentadas as principais ferramentas utilizadas. Os circuitos projetados so apresentados em simulao no Proteus VSM (LABCENTER, 2008) e so feitas consideraes sobre os componentes utilizados e sobre o funcionamento desses circuitos. Na seo projeto de software so feitas consideraes tericas e de implementao relacionadas a cada software embarcado, em seguida so apresentados os fluxogramas e so feitas as respectivas descries e consideraes.

4.1. METODOLOGIA
Inicialmente o desenvolvimento do sistema embarcado foi dividido em duas etapas: circuito para monitoramento de temperatura e circuito para conexo em rede Ethernet. Antes de iniciar o projeto desses circuitos, foram realizados estudos sobre os microcontroladores PIC da Microchip e a respectiva programao em linguagem C dos mesmos. Os estudos foram concentrados nos perifricos dos microcontroladores que so utilizados no hardware do projeto. Ento, foram estudados os blocos de E/S digital, conversor A/D, mdulo MSSP no modo SPI e o bloco de temporizao Timer 0. Posteriormente, foram realizados estudos sobre programao em linguagem C desses recursos. Na fase anterior fase de projeto dos circuitos, para fins de estudo, foram elaborados esquemas eletrnicos simples e os respectivos programas para a utilizao dos perifricos que so utilizados no sistema microcontrolado. Os circuitos e programas desenvolvidos nessa fase de estudo foram: circuito para manipulao de E/S digital, entrada analgica, temporizao com Timer 0 e interfaceamento com display LCD. Posteriormente, os esquemas eletrnicos e programas foram testados utilizando o simulador Proteus VSM, onde os esquemas e respectivos programas puderam ser validados. Aps ter sido realizada a familiarizao com os microcontroladores, sua programao e recursos, o circuito para monitoramento de temperatura foi desenvolvido, seguindo o processo de elaborao dos esquemas dos circuitos e respectivos programas e validao a partir do uso do simulador. O projeto desse circuito foi realizado de forma modular, a partir do desenvolvimento de dois circuitos integrantes: circuito para interfaceamento com o sensor de temperatura LM 35 e circuito para interfaceamento com display LCD. O circuito de monitoramento de temperatura basicamente a unio dos dois circuitos citados anteriormente. J com o esquema final do circuito de monitoramento de temperatura, bem como o programa embarcado utilizado, foram realizadas as primeiras montagens de circuitos utilizando protoboard (matriz de contatos). Inicialmente, foram montados circuitos bsicos para manipulao de I/O digital, entrada analgica e interfaceamento com display. Essas 37

montagens iniciais foram feitas para permitir uma melhor familiarizao com os equipamentos eletrnicos adquiridos (fonte de alimentao, gravador/depurador de microcontroladores, multmetro e protoboard) e os componentes eletrnicos (microcontroladores, cristal, display LCD, dentre outros). Em seguida, o circuito de interfaceamento com o sensor LM 35 foi montado em protoboard, a temperatura ambiente era apresentada codificada em binrio utilizando 8 leds. Posteriormente, o circuito para interfaceamento com display foi montado em protoboard exibindo uma mensagem constante no display, apenas para verificar se o programa embarcado no microcontrolador estava se comunicando com o display e se o display estava funcionando corretamente. A partir da montagem desses dois circuitos em protoboard foi montado o circuito para monitoramento de temperatura que formado por esses dois circuitos. Assim, a primeira parte do sistema microcontrolado do projeto foi finalizada. O passo seguinte foi o estudo de aspectos ligados tecnologia Internet Embarcada, como a documentao tcnica e cdigo-fonte da pilha TCP/IP (MICROCHIP, 2008) da Microchip que especfica para utilizao em microcontroladores e DSPs (Processadores Digitais de Sinais). Em seguida, foi realizado o estudo sobre o controlador Ethernet ENC28J60 da Microchip, esse estudo foi concentrado principalmente nas caractersticas do controlador, nos blocos internos, no esquema de comunicao com microcontroladores e no conjunto de componentes externos necessrios ao seu funcionamento. Em seguida, foi estudado o MPFS (Microchip File System), que permite o armazenamento de dados em formato binrio no microcontrolador e as funes do Microchip HTTP Server, relacionadas gerao de pginas HTML dinmicas a partir do microcontrolador. Em seguida, foi elaborado um esboo do esquema eletrnico completo do sistema microcontrolado que composto pelo circuito para monitoramento de temperatura e o circuito para conexo em rede Ethernet. Atravs da unio desses dois circuitos formado o circuito para monitoramento de temperatura e disponibilizao dos dados via rede de computadores. Em seguida, assim como no projeto dos circuitos citados anteriormente, foi realizada a validao, utilizando simulador, do circuito e software (j com pilha TCP/IP embarcada) para monitoramento de temperatura. Nesse momento, ficou claro o poder e qualidade do simulador, j que o mesmo simulou a conexo de um hardware microcontrolado em rede perfeitamente, com funcionamento e dinmica idntica de um hardware que utiliza a tecnologia Internet embarcada. Tambm se constatou que a montagem desse hardware levou muito tempo, no pela dificuldade da montagem, mas principalmente pela dificuldade de aquisio de peas e componentes no mercado nacional, j descartando o mercado local. Tentou-se comprar a interface de rede, por exemplo, inicialmente fora do pas, mas no houve resposta da empresa responsvel; trs meses depois a mesma passou a ser comercializada no Brasil, sendo adquirida um ms depois. Alm da prpria interface de rede, mais difcil ainda foi encontrar, em curto prazo, os componentes passivos (indutores e resistores), que so especficos para utilizao com o controlador ENC28J60, sendo os responsveis pela gerao do sinal no padro Ethernet, ou seja, de importncia fundamental para o sistema embarcado. Como o sistema embarcado apenas um dos componentes integrantes do projeto e sua especificao completa j havia sido definida, o foco do projeto passou ento a ser os demais programas e sistemas necessrios para o projeto, que no haviam ainda sido desenvolvidos, j que sua importncia e utilidade so dependentes da existncia do sistema embarcado e da sua capacidade de disponibilizar os dados via rede de computadores. A simulao foi utilizada como ferramenta de apoio quando o 38

sistema embarcado era necessrio, como por exemplo, no processo de desenvolvimento da pgina HTML embarcada no microcontrolador e na comunicao remota com o daemon de aquisio de dados.

4.2. FERRAMENTAS UTILIZADAS

Essa seo apresenta, de forma breve, as principais ferramentas utilizadas no processo de desenvolvimento e especificao do sistema embarcado.

4.2.1. MPLAB IDE

O MPLAB (MICROCHIP, 2008) um IDE (Ambiente de Desenvolvimento Integrado) gratuito desenvolvido pela Microchip. Ele dispem de um conjunto de ferramentas (editor, simulador, gravador, depurador e compilador) para o desenvolvimento de aplicaes embarcadas, baseadas nos microcontroladores da linha PIC e DsPIC da Microchip. O MPLAB executa como um aplicativo de 32 bits no sistema operacional Microsoft Windows, de fcil utilizao e possui um conjunto de aplicativos para desenvolvimento e depurao de forma rpida e gil de aplicaes embarcadas baseadas nos produtos da Microchip. O ambiente do MPLAB pode ser visto na Figura 4.1.

Figura 4.1 - Ambiente de trabalho do MPLAB IDE.

39

4.2.2. COMPILADOR MPLAB C18 PARA MICROCONTROLADORES PIC18F

O MPLAB C18 (MICROCHIP, 2008) um compilador comercial para a linguagem de programao C ANSI, desenvolvido especificamente para linha de microcontroladores PIC 18 da Microchip. O MPLAB C18 executa como aplicativo console de 32 bits no sistema operacional Microsoft Windows e possui total integrao com ambiente integrado de desenvolvimento MPLAB IDE, permitindo depurao em nvel de cdigo com o software MPLAB e em nvel de hardware com depuradores como o ICD2BR. A organizao do projeto, opes de compilao e customizao de arquivos linker pode ser toda feita pelo MPLAB IDE, que disponibiliza uma interface grfica amigvel para o compilador. Algumas caractersticas do compilador MPLAB C18 podem ser vistas a seguir: Compatibilidade com C ANSI 89; Integrao com o MPLAB IDE a fim de facilitar a gerncia de projeto e a depurao em nvel de cdigo-fonte; Compatibilidade com o assembler MPASM, o que permite total liberdade para integrao de cdigo C e Assembly; Eficiente gerao de cdigo com mltiplos nveis de otimizao; Uma grande biblioteca de funes para o usurio, incluindo PWM, SPI, I2C, USART, manipulao de strings e funes matemticas; Disponibilidade de uma verso gratuita para estudantes.

4.2.3. PROTEUS VSM

O Proteus (LABCENTER, 2008) um conjunto de programas para o desenvolvimento de sistemas eletrnicos. Ele possui ferramentas para projeto de placas de circuito impresso (ARES), para criao de prottipos de circuitos (ISIS) e simulao animada de circuitos (VSM). O Proteus o nico software que oferece habilidade de co-simulao de sistemas microcontrolados, tanto em alto nvel quanto em baixo nvel integrado, ao simulador de circuitos SPICE. O Proteus VSM (Virtual System Modelling) combina uma integrao com o simulador de circuitos SPICE, componentes animados e modelos de microprocessadores para facilitar a co-simulao completa de sistemas baseados em microcontroladores. A princpio possvel desenvolver e testar um projeto utilizando o Proteus VSM, antes mesmo de o prottipo fsico estar construdo. Isso possvel porque o Proteus VSM simula, atravs de animao em tempo real (ou bem prximo disso) a integrao e funcionamento de todos os componentes de um projeto e oferece instrumentos virtuais (Osciloscpio, Multmetro, Analisador lgico, dentre outros) para depurao dos circuitos. Na Figura 4.2 pode ser vista a placa PICDEM2+, desenvolvida pela Microchip, para treinamento e desenvolvimento de sistemas baseados nos microcontroladores da famlia PIC 40

18F. Na Figura 4.3 pode ser vista a mesma placa em total simulao e animao no Proteus VSM.

Figura 4.2 - Placa PICDEM2+ da Microchip.

Figura 4.3 - Placa PICDEM2+ no ambiente ISIS e simulada atravs do Proteus VSM.

41

4.3. PROJETO DE HARDWARE

Essa seo descreve o projeto, lista de componentes e funcionamento do circuito microcontrolado para monitoramento de temperatura e circuito microcontrolado para monitoramento de temperatura e disponibilizao dos dados via conexo de rede. So mostrados os esquemas eletrnicos j em simulao no Proteus VSM e feita uma breve descrio do funcionamento de cada um dos circuitos apresentados. Os circuitos projetados so componentes da arquitetura do hardware proposto. Um esboo da mesma pode ser visto na Figura 4.4.

Figura 4.4 - Esboo da arquitetura do "hardware" proposto.

O princpio de funcionamento do hardware proposto pode ser explicado utilizando como base as duas formas com que a temperatura estar disponvel para visualizao por parte do usurio: localmente e remotamente. Na primeira forma, o sensor de temperatura obtm o valor da temperatura ambiente e a transmite para o microcontrolador, que recebe este dado e, atravs de um conversor analgico/digital (ADC) interno, realiza a respectiva converso e transfere o dado j no formato digital para ser exibido no display LCD. J na segunda forma, o hardware conectado atravs da sua interface de rede e do controlador Ethernet a um segmento de rede e, dessa forma, passa a ser um host nesse segmento. A comunicao entre o controlador Ethernet e o microcontrolador (MCU) feita atravs do protocolo SPI, que um protocolo utilizado para comunicao entre circuitos integrados. O microcontrolador (MCU) possui embarcada uma pilha TCP/IP (ver seo 4.4.4.1.1.), que permitir a comunicao entre o hardware proposto e os outros dispositivos conectados a rede. Assim como nas pilhas TCP/IP tradicionais, a pilha TCP/IP embarcada utilizada para encapsular servios tpicos da camada de aplicao, como: HTTP, FTP, SMTP, dentre outros. Alm da pilha TCP/IP, o microcontrolador ter gravado em sua memria interna uma pgina HTML, que ser apresentada ao usurio com a respectiva temperatura atual. Dessa forma, um usurio com conexo a Internet e atravs de um navegador WEB poder visualizar, atravs de uma requisio HTTP, a temperatura no ambiente monitorado, bastando apenas acessar o IP do servidor microcontrolado atravs da URL obtida pelo navegador.

42

4.3.1. CIRCUITO MICROCONTROLADO PARA MONITORAMENTO DE TEMPERATURA

O objetivo desse circuito ler o dado de temperatura gerado pelo sensor LM 35 e possibilitar a visualizao do mesmo no display LCD. Esse circuito pode ser visto na Figura 4.5.

Os componentes desse circuito so: Um microcontrolador PIC18F2620 (Componente U1 da Figura 4.5); Um display LCD compatvel com o JHD 204 (Componente LCD1 da Figura 4.5); Um sensor de temperatura LM 35 (Componente U2 da Figura 4.5); Um cristal de 25MHz; Dois capacitores de 15pF (C1 e C2);

Figura 4.5 - Simulao do circuito microcontrolado para monitoramento de temperatura.

O sensor de temperatura LM 35 mede a temperatura ambiente e gera uma tenso em mV proporcional a essa temperatura. Um fato importante que na configurao que o LM35 est sendo utilizado, o mesmo medir temperaturas na faixa de 2C a 150C. De fato isso uma limitao, mas para medir uma faixa mais ampla, incluindo valores negativos, seria necessrio adicionar uma fonte simtrica ao circuito. Assim, essa capacidade adicional foi deixada para uma fase futura de melhorias no circuito.

43

Inicialmente o microcontrolador envia os textos estticos RNP PoP-RN, Temperatura e C. Em seguida o microcontrolador l o sinal analgico gerado pelo sensor de temperatura LM 35, atravs do pino RA0, que est configurado como uma entrada analgica. Atravs do mdulo conversor A/D interno, o microcontrolador converte o sinal para digital e o formata para exibio no display. Logo em seguida os dados so enviados para o PORTB (pinos RB0 a RB6), onde o display LCD est conectado e o mesmo exibe o valor de temperatura lido. Neste exemplo, a temperatura fornecida pelo LM 35 era 28C. O circuito para monitoramento de temperatura pode ser visto montado em protoboard na Figura 4.6.

Figura 4.6 - Circuito para monitoramento de temperatura montado em "protoboard".

44

4.3.2. CIRCUITO MICROCONTROLADO PARA MONITORAMENTO DE TEMPERATURA E DISPONIBILIZAO DOS DADOS ATRAVS DE CONEXO DE REDE
O objetivo deste circuito obter os dados de temperatura a partir de um sensor LM 35 e possibilitar a viso local (atravs do display LCD) e remota (atravs da Internet) desses dados. Esse circuito pode ser visto na Figura 4.7. Os componentes desse circuito so: Um microcontrolador PIC18F4620 (Componente U1 da Figura 4.7); Um display LCD compatvel com o JHD 204 (Componente LCD1 da Figura 4.7); Um controlador Ethernet ENC28J60 (Componente U2 da Figura 4.7); Um sensor de temperatura LM 35 (Componente U3 da Figura 4.7); Um cristal de 25MHz; Dois capacitores de 15pF (C1 e C2);

Figura 4.7 - Simulao do circuito microcontrolado para monitoramento de temperatura e disponibilizao dos dados via Internet.

Duas formas simples de explicar o funcionamento desse circuito, baseiam-se na maneira como a temperatura ser visualizada pelo usurio: localmente ou remotamente. Quando o usurio deseja verificar a temperatura localmente, olhando para a placa, por exemplo, o processo similar ao discutido na seo 4.3.1. Mas como esse circuito possui conexo Ethernet, o processo completo bem mais complexo e envolve mais etapas, j que h uma pilha TCP/IP 45

embarcada no microcontrolador junto com o software de aplicao para o monitoramento de temperatura. Mas, basicamente, inicialmente feita a inicializao da pilha TCP/IP e dos respectivos mdulos utilizados, como por exemplo, o MAC, TCP, IP, HTTP, dentre outros. Aps a pilha TCP/IP ser inicializada corretamente e o circuito microcontrolado j estar em rede, o passo seguinte enviar o texto esttico com as informaes sobre o endereo IP, MAC, dentre outras. S depois de todo esse processo, a primeira amostra de temperatura, obtida a partir do LM 35 vai ser lida, formatada e apresentada no display. Pode parecer complexo e pode-se imaginar que o processo demorado, mas o mesmo ocorre em alguns poucos milissegundos, desde que a pilha TCP/IP esteja corretamente configurada e o programa de aplicao seja otimizado. Como os microcontroladores no possuem ainda capacidade multithread, h apenas um fluxo de execuo no mesmo. Assim, se uma operao demorar, a mesma pode comprometer todo o desempenho do sistema e influenciando de forma negativa, ou at mesmo inviabilizando a conexo deste microcontrolador em rede, j que o mesmo no ter capacidade de processar de forma satisfatria os pacotes recebidos e responder aos clientes, antes que ocorra um time-out nos mesmos. Quando o usurio deseja visualizar os dados remotamente, o mesmo deve enviar uma requisio HTTP para o circuito microcontrolado, que est em rede e se comporta normalmente como um host nessa rede. Essa requisio pode ser feita atravs da digitao do IP (neste caso, 192.168.0.50) do circuito microcontrolado na URL de um browser (navegador), dessa forma o circuito vai interpretar a requisio do navegador do usurio e gerar, atravs de um servidor HTTP interno, uma pgina HTML de resposta ao usurio. Esta pgina contm o valor da temperatura lida pelo LM 35 no momento da recepo da requisio no microcontrolador. A pgina gerada pelo servidor HTTP microcontrolado pode ser vista na Figura 4.8.

Figura 4.8 - Pgina para monitoramento de temperatura gerada por um servidor HTTP microcontrolado.

46

O circuito apresentado na Figura 4.7 tambm pode ser utilizando com o software embarcado cliente TCP microcontrolado. A Figura 4.9 apresenta, em simulao, a comunicao via socket entre o circuito utilizando o software cliente TCP microcontrolado e um servidor TCP executando em um computador do tipo PC. Um ponto importante que o Proteus ISIS e VSM na verso 7.2, que foi utilizada para elaborao da simulao, simplifica bastante o uso do controlador ENC28J60 e abstrai vrios componentes que seriam necessrios para o funcionamento do mesmo, como indutores, resistores, transformadores e todos os demais componentes comentados na seo 3.4. Dessa forma, esse esquema deve ser observado apenas para fins de simulao. No deve ser utilizado como esquema para montagem de um circuito com conexo Ethernet, j que muitos componentes essenciais, necessrios na montagem do circuito real, so abstrados pelo simulador. A complexidade da simulao se concentra basicamente na configurao da pilha TCP/IP (que est embarcada no microcontrolador), de forma a permitir seu funcionamento com esse circuito. A Microchip no disponibiliza todas as configuraes e variaes possveis para o uso da pilha TCP/IP com qualquer microcontrolador. Ento, esse um processo de configurao da pilha TCP/IP embarcada que depende muito do conhecimento do usurio sobre a arquitetura do microcontrolador, protocolo SPI, protocolos de rede e programao em C em baixo nvel.

Figura 4.9 - Comunicao entre um cliente TCP microcontrolado e um servidor TCP remoto baseado em um PC.

47

4.4. PROJETO DE SOFTWARE

Essa seo descreve os aspectos tericos e de implementao dos diversos programas embarcados, desenvolvidos para utilizao nos circuitos microcontrolados especificados na seo 4.3. So feitas consideraes tericas sobre os recursos utilizados dos microcontroladores, bem como as funes mais importantes utilizadas e os fluxogramas que descrevem esses programas.

4.4.1. SOFTWARE EMBARCADO PARA INTERFACEAMENTO COM SENSOR DE TEMPERATURA LM35

Essa seo descreve os aspectos tericos de recursos e perifricos utilizados dos microcontroladores para interfaceamento com o sensor LM35. Inicialmente, so feitas consideraes sobre teoria e uso de conversores A/D nos microcontroladores especificados. Alm disso, so apresentadas as principais funes utilizadas na implementao do software e, em seguida, apresentado um fluxograma que descreve essa implementao.

4.4.1.1. CONSIDERAES TERICAS

Os sensores de temperatura geralmente fornecem uma informao analgica, como por exemplo, tenso, que proporcional temperatura medida. Ento, para essa temperatura ser internamente processada no microcontrolador, de forma a poder ser posteriormente exibida em um display ou conjunto de leds, necessrio o uso de um conversor A/D. Como visto no capitulo 3, os microcontroladores j dispem de um internamente. A resoluo da converso depende da menor tenso lida pelo conversor A/D que produz variao correspondente na sada do mesmo, ou seja, o menor valor que pode ser medido pelo conversor. A resoluo pode ser calculada pela seguinte frmula:

resoluo =

tensodereferncia 2 NmeroDeBits

48

Cada um dos diversos bits que compe a informao digitalizada responsvel por uma parcela do valor da informao analgica a ser convertida. Dessa forma, a soma da contribuio de todos esses bits forma a tenso de entrada do conversor A/D. Logo, a parcela de tenso de um determinado bit do conversor A/D pode ser determinada pela seguinte frmula:

tensodeentrada =

valordobit 2 (bit 1) tensodereferncia 2 NmeroDebits

Percebe-se que apenas os bits de valor 1 representam alguma parcela da tenso analgica, j que os bits de valor 0 no contribuem para formar a tenso de entrada. Quanto maior a quantidade de bits, maior a exatido e resoluo do conversor. O PIC18F2620 utilizado nos circuitos que empregam o sensor LM 35 possui um conversor A/D interno de 10 bits. Existem diversas tcnicas de converso A/D, o PIC18F2620 utiliza a tcnica de aproximaes sucessivas. Nessa tcnica a converso realizada do bit mais significativo para o menos significativo. O motivo dessa escolha bem simples, o bit mais significativo j representa a metade da tenso de referncia, conhecer o valor lgico desse bit j indica se a tenso de entrada maior ou menor que a metade da referncia. Em seguida, analisa-se o prximo bit mais significativo e o mesmo representa a (metade) da metade da tenso de referncia, o processo se repete at o bit menos significativo. Supondo, por exemplo, um conversor A/D de quatro bits com tenso de referncia a 5 V, a tabela com a parcela de tenso de cada bit representa pode ser vista na Tabela 4.1

Tabela 4.1 - Parcela de tenso que cada "bit" representa em um conversor A/D de 4 bits com referncia em 5 Volts.

Bit 4 3 2 1

Tenso 2,5 V 1,25 V 0,625 V 0,3125 V

49

Supondo que a tenso de entrada seja de 3,3 V. Neste caso os passos de converso seriam os seguintes: 1. Testa-se o bit mais significativo, ou seja, a tenso de entrada maior que 2,5 V? Sim, logo esse bit vale 1. 2. Teste-se o prximo bit, ou seja, a tenso de entrada maior do que 3,75V (2,5V + 1,25V)? No, portanto, este bit 0. 3. Testa-se o prximo bit, ou seja, a tenso de entrada maior do que 3,125V (2,5 V + 0,625V)? Sim, portanto, este bit 1. 4. Finalmente testa-se o bit menos significativo, ou seja, a tenso de entrada maior do que 3,4375 (2,5V + 0,625V + 0,3125V)? No, portanto, este bit 0 e o valor binrio da converso 1010. A vantagem dessa tcnica de converso sua rapidez, j que para um conversor A/D de n bits so necessrias apenas n iteraes, independente do valor a ser convertido. No caso anterior, como o conversor era de quatro bits, foram necessrias quatro iteraes. Apesar de o PIC18F2620 possuir 11 canais analgicos como foi visto na seo 3.1.9.3, internamente s existe um mdulo de converso. Logo, apenas um canal pode ser utilizado por vez. Se forem necessrios vrios canais, a multiplexao do uso do conversor A/D deve ser definido pelo software embarcado desenvolvido pelo usurio. Como o microcontrolador possui 11 canais analgicos, deve-se definir, de acordo com o projeto, a quantidade de canais necessrios. Podem ser utilizados todos os canais ou apenas um, deixando os demais pinos configurados como E/S digitais. Uma pequena desvantagem dos microcontroladores PIC que os canais no podem ser escolhidos individualmente, sendo necessrio ento verificar a Figura 4.10 e escolher a configurao que mais se adqua ao projeto.

Figura 4.10 - Configuraes possveis dos canais A/D para o PIC18F2620.

50

A configurao dos canais analgicos utilizados feita atravs dos quatro primeiros bits (registradores PCFG) do registrador de controle ADCON1. Alm da configurao dos bits conforme a tabela apresentada, tambm necessrio configurar o registrador TRIS do PORT associado ao pino que se deseja utilizar como entrada analgica, definindo o mesmo com o valor 1, que significa que esse pino ser utilizado como entrada de dados. Outra informao importante disponvel na tabela no que diz respeito s tenses de referncia. A converso realizada comparando-se a tenso de entrada com as tenses de referncia Vref+ e Vref-. Logo, quando a tenso de entrada for igual a Vref+, a converso resultar no valor mximo (1023) e quando a mesma for igual a Vref-, ento o resultado da converso ser o valor mnimo (0). Com intuito de evitar problemas de rudo e variaes da entrada analgica durante o processo de converso, o microcontrolador utiliza o processo de sample-and-hold (S-H). Internamente, o microcontrolador possui um capacitor de 25pF, que conectado ao canal analgico em uso. Quando o processo de converso propriamente dito iniciado, o capacitor desconectado automaticamente do canal analgico, dessa forma a tenso sobre o capacitor mantida constante. A tenso analgica utilizada durante todo o processo de converso a existente nesse capacitor e no mais a do canal analgico. Logo, mesmo que a tenso no canal varie a converso no afetada. O processo de converso A/D do microcontrolador possui 5 fases. So elas:

1. Adequao do capacitor: O capacitor, em geral, permanece o tempo todo ligado ao sistema de entradas analgicas, ficando desligado apenas durante o processo de converso. Supondo que o mesmo esteja monitorando um canal com uma tenso que tende a zero e, posteriormente, seja chaveado para monitorar um canal que esteja com uma tenso de 5 V na entrada, o capacitor ter que ser completamente carregado com essa tenso, para que o processo de converso possa ser iniciado. Obviamente, essa carga leva algum tempo: o tempo mnimo de 1.4 s para uma fonte de tenso analgica que possui a impedncia mnima de 50 e 2.4 s para a impedncia mxima indicada que 2.5 K. Percebe-se que esse tempo depende da impedncia de entrada, mas tambm da diferena de tenso entre a entrada e o capacitor e da temperatura. Quanto menor a impedncia menor o tempo de adequao.

2. Desligamento do capacitor: Depois do incio do processo de converso, o capacitor ser desligado internamente do circuito de entrada. Esse processo feito em aproximadamente 100 ns, sendo dessa forma, um valor praticamente desprezvel.

51

3. Converso: O tempo de converso um dado importante e est diretamente relacionado com a freqncia de trabalho do conversor A/D. Para que o sistema de converso funcione, um sinal de clock deve ser aplicado ao conversor A/D. Cada perodo desse clock chamado de TAD e representa o tempo de converso de 1 bit. Como o conversor do microcontrolador de 10 bits, so necessrios 11 TAD no total, o TAD adicional o tempo necessrio decorrido entre a fase de adequao e o incio do processo de converso. O valor do TAD depende da freqncia empregada.

4. Religamento do capacitor: No final da converso os registradores de resultado so atualizados com o respectivo valor da converso, o valor da flag de interrupo alterado e o capacitor ento desligado. O tempo mnimo recomendado para esse processo de 2 TAD.

5. Nova adequao do capacitor: Durante o tempo de converso, a tenso no capacitor no foi alterada. Mas no trmino do processo, o mesmo ser novamente ligado na entrada analgica, que pode ter sofrido uma variao brusca de tenso devido mudana de canal, por exemplo. Logo, no intervalo entre uma converso e outra necessrio um tempo para uma nova adequao do capacitor, sendo recomendado o tempo mximo, que de 2.4 s, como foi visto no item adequao do capacitor, cujas informaes tambm so vlidas para este item.

Depois da configurao dos canais utilizados, necessrio realizar a configurao da freqncia de trabalho. Isso feito atravs dos trs primeiros bits do ACQT, que correspondem aos bits 3, 4 e 5 do registrador ADCON2. Como foi discutido anteriormente, a freqncia de trabalho est relacionada freqncia de oscilao que est sendo utilizada pelo circuito, podendo a mesma ser gerada por um oscilador externo ou pelo oscilador RC interno do microcontrolador. Alm disso, o clock utilizado pelo conversor A/D pode ser configurado via software. A freqncia de trabalho ser igual freqncia de oscilao dividida por um dos seguintes fatores: 2, 4, 8, 16, 32 e 64, sendo que os mesmos podem ser selecionados via software. O clock da converso A/D (TAD) deve ser o menor possvel, mas deve estar entre os valores possveis de TAD que so: 0.7s e 25s. A Tabela 4.2 apresenta uma relao entra a configurao dos bits do registrador de controle referente ao TAD, o fator de configurao do TAD correspondente a mxima freqncia possvel que os osciladores do sistema podem utilizar para garantir a operao correta do conversor A/D.

52

Tabela 4.2 Mxima freqncia possvel para permitir a operao correta do conversor A/D.

Clock da converso A/D Operao 2 Tosc 4 Tosc 8 Tosc 16 Tosc 32 Tosc 64 Tosc RC ADCS2:ADCS0 000 100 001 101 010 110 X11

Mxima freqncia por dispositivo PIC18F2X20/4X20 2.86 MHz 5.71 MHz 11.43 MHz 22.86 MHz 40.0 MHz 40.0 MHz 1.00 MHz PIC18LF2X20/4X20 1.43 KHz 2.86 MHz 5.72 MHz 11.43 MHz 22.86 MHz 22.86 MHz 1.00 MHz

O ltimo passo a ser configurado diz respeito forma como o resultado da converso deve ser armazenado nos registradores ADRESH e ADRESL. Como o resultado possui 10 bits e os registradores do microcontrolador possuem apenas 8 bits cada, um registrador deve ficar com os 8 bits e o outro com 2 bits do resultado. Mas como esses dois registradores juntos possuem 16 bits, o resultado pode ser justificado a esquerda ou a direita. O bit ADFM do registrador ADCON1 define se resultado ser justificado a direita (valor 1), utilizando todos bits do registrador ADRESH e apenas os dois primeiros bits do registrador ADRESL ou esquerda (valor 0), utilizando todos bits do registrador ADRESH e apenas os dois ltimos bits do registrador ADRESL. Resumindo, depois de iniciado o processo de converso, o capacitor interno desligado do circuito de entrada e a converso executada em 11TAD e logo no prximo ciclo de mquina, os registradores ADRESH e ADRESL so atualizados com o resultado. Nesse momento, o bit GO/DONE do registrador ADCON0 volta automaticamente para 0 e pode ser monitorado pelo programa para checar o trmino da converso. Alm disso, o flag de interrupo PIR1 do registrador ADIF tambm ativado. Caso seja atribudo o valor 0 ao registrador GO/DONE, a converso ser abortada e os registradores ADRESH e ADRESL no sero alterados.

4.4.1.2. CONSIDERAES DE IMPLEMENTAO

A implementao do software embarcado foi feita na linguagem C (ANSI) e foram utilizadas as bibliotecas do compilador C18, que o compilador especfico da Microchip para os microcontroladores da famlia PIC 18.

53

A seguir feita uma breve descrio das principais funes utilizadas, que se relacionam com o perifrico conversor A/D do microcontrolador. As funes e respectivas consideraes podem ser vistas na Tabela 4.3.

Tabela 4.3 - Descrio das principais funes do compilador C18 relacionadas ao conversor A/D.

BusyADC
Descrio Biblioteca Prottipo Observaes Verificar se o conversor A/D est realizado uma converso em determinado momento. adc.h char BusyADC( void ); Essa funo verifica se o perifrico conversor A/D est no processo de converso de um dado analgico. 1, Se o conversor A/D est realizando uma converso. 0, Se o conversor A/D no est realizando nenhuma converso.

Valor de retorno

CloseADC
Descrio Biblioteca Prottipo Observao Desabilita o conversor A/D adc.h void CloseADC( void ); Essa funo desabilita o conversor A/D e o mecanismo de interrupo A/D.

ConvertADC
Descrio Biblioteca Prottipo Observao Inicia o processo de converso A/D adc.h void ConvertADC( void ); Inicia o processo de converso A/D, a funo busyADC( ) deve ser utilizada para verificar o fim da converso.

ReadADC
54

Descrio Biblioteca Prottipo Observao Valor de retorno

L o resultado da converso A/D. adc.h int ReadADC( void ); Essa funo l um valor de 16 bits que representa o resultado da converso A/D. Essa funo retorna o um valor de 16 bits. Dependo da configurao do conversor A/D, o resultado poder conter o resultado nos 16 bits mais ou menos significativos.

OpenADC
Descrio Biblioteca Prottipo Configura o conversor A/D. adc.h void OpenADC(unsigned char config, unsigned char config2 , unsigned char portconfig); Argumentos Config: uma mscara de bits formada por operaes AND com os valores de cada uma das categorias listadas abaixo:

Clock do conversor A/D:

ADC_FOSC_2 ADC_FOSC_4 ADC_FOSC_8 ADC_FOSC_16 ADC_FOSC_32 ADC_FOSC_64 ADC_FOSC_RC FOSC / 2 FOSC / 4 FOSC / 8 FOSC / 16 FOSC / 32 FOSC / 64 Oscilador RC Interno

55

Justificao do resultado A/D:

ADC_RIGHT_JUST Resultado nos bits menos significativos ADC_LEFT_JUST Resultado nos bits mais significativos

Tempo de aquisio:

ADC_0_TAD 0 Tad ADC_2_TAD 2 Tad ADC_4_TAD 4 Tad ADC_6_TAD 6 Tad ADC_8_TAD 8 Tad ADC_12_TAD 12 Tad ADC_16_TAD 16 Tad ADC_20_TAD 20 Tad

config2 uma mscara de bits formada por operaes AND com os valores de cada uma das categorias listadas a seguir:

Canal:

ADC_CH0 Channel 0 ADC_CH1 Channel 1 ADC_CH2 Channel 2 ADC_CH3 Channel 3 ADC_CH4 Channel 4 ADC_CH5 Channel 5 ADC_CH6 Channel 6 ADC_CH7 Channel 7

56

ADC_CH8 Channel 8 ADC_CH9 Channel 9 ADC_CH10 Channel 10 ADC_CH11 Channel 11 ADC_CH12 Channel 12 ADC_CH13 Channel 13 ADC_CH14 Channel 14 ADC_CH15 Channel 15

Interrupo A/D:

ADC_INT_ON Interrupo A/D habilitada ADC_INT_OFF Interrupo A/D desabilitada

Configurao de voltagem do conversor A/D:

ADC_VREFPLUS_VDD ADC_VREFPLUS_EXT ADC_VREFMINUS_VDD ADC_VREFMINUS_EXT

VREF+ = AVDD VREF+ = external VREF- = AVDD VREF- = external

portconfig O portconfig um valor de 0 a 15 que configura os primeiros 4 bits do registrador ADCON1, que so os bits de configurao do port. Observao Essa funo reseta o conversor A/D, o colocando no estado POR (Power-on Reset) e configura o clock do conversor, o formato do resultado, voltagem de referncia, port e canal.
OpenADC( ADC_FOSC_32 & ADC_RIGHT_JUST & ADC_12_TAD, ADC_CH0 & ADC_INT_OFF, 15 );

Exemplo

57

No software embarcado para interfaceamento com LM 35, o conversor A/D foi configurado com as seguintes caractersticas: Clock do conversor: diviso da freqncia externa por 8; Formato do resultado: justificado a direita; Tempo de aquisio: 12 TAD; Canal utilizado: canal 0; Interrupo da converso A/D: desligada; Tenso de referncia: interna baseada nos valores de Vdd e Vss. Para estabelecer essa configurao a funo OpenADC deve ser utilizada com os seguintes parmetros:
OpenADC(ADC_FOSC_8 & ADC_RIGHT_JUST & ADC_12_TAD, ADC_CH0 & ADC_INT_OFF & ADC_VREFPLUS_VDD & ADC_VREFMINUS_VSS, 14);

4.4.1.3. FLUXOGRAMA
O fluxograma do software embarcado para interfaceamento do microcontrolador com sensor LM 35 pode ser visto na Figura 4.11. Basicamente, o programa inicialmente define todos os pinos do PORTB como sada, j que os oito leds para apresentao do resultado esto conectados a esses pinos. Em seguida, limpa o PORTB atravs de atribuio do valor 0x00 (0 em decimal), a fim de garantir consistncia na apresentao do resultado. Posteriormente, o pino RA0 definido como uma entrada e o conversor A/D configurado com os devidos parmetros, utilizando o pino RA0 como entrada analgica. A partir desse momento, o programa fica em loop infinito realizando converses e exibindo o resultado nos 8 leds. Inicialmente, espera-se 20 microsegundos, inicia-se o processo de converso, em seguida verificado se a converso foi terminada, caso no tenha sido, o programa continua verificando essa condio at que seja verdadeira. Assim que a converso for concluda, o valor da mesma convertido para graus Celsius e apresentado nos 8 leds.

58

Figura 4.11 - Fluxograma do "software" embarcado para interfaceamento do microcontrolador com o sensor LM35.

59

4.4.2. SOFTWARE EMBARCADO PARA INTERFACEAMENTO COM DISPLAY LCD

Essa seo descreve os aspectos tericos necessrios para o interfaceamento do microcontrolador com o display LCD. So feitas consideraes tericas sobre a utilizao do LCD, sua inicializao e configurao. Alm disso, so apresentadas as funes utilizadas pelo software e o fluxograma que caracteriza o mesmo.

4.4.2.1. CONSIDERAES TERICAS

Os mdulos LCD so perifricos que tornam muita prtico o processo de visualizao de dados. Em geral, um mdulo LCD composto basicamente de um controlador de display, que responsvel por processar os comandos enviados para o mesmo e de um display de cristal liquido (LCD) para exibir os dados. Os displays alfanumricos so mais baratos e mais adequados para apresentar caracteres como nmeros, letras e smbolos, sendo sua tela dividida e organizada de forma matricial em linhas e colunas, onde cada posio dessa matriz pode armazenar um nico caractere. No projeto foi utilizado o display LCD JHD204A (JHD204, 2005), que utiliza o controlador S6A0069 (SAMSUNG, 2000), que compatvel com o controlador HD 44780, considerado um padro. Esses controladores permitem uma comunicao simples com sistemas microcontrolados, possuindo largura de barramento que pode ser de 4 ou 8 bits, alm de um conjunto de trs sinais de controle: ENABLE, R/W e RS. A comunicao em 4 bits realizada utilizando as linhas mais significativas do barramento de dados (D7 a D4), dividindo o byte de controle em dois nibbles que so transferidos, iniciando-se pelo mais significativo. O controlador do display deve receber comandos para realizar as diversas operaes possveis. Mas antes de enviar comandos para o mesmo, ele deve ser inicializado. H todo um procedimento padro que leva em considerao a temporizao para poder realizar a inicializao. O fluxograma do processo de inicializao, que deve ser feito pelo software do usurio, pode ser visto na Figura 4.12.

60

Figura 4.12 - Procedimentos necessrios para a inicializao do display LCD.

61

Aps o processo de inicializao do display, o cursor ir para a posio 0x00 (primeira linha e primeira coluna). A cada dado (caractere) que enviado para o display, o mesmo automaticamente desloca o cursor para a prxima posio, evitando dessa forma, que o usurio precisa posicionar o cursor na posio seguinte toda vez que deseja enviar um caractere. Mas, caso a inteno seja escrever em uma posio que no imediatamente consecutiva, devese posicionar o cursor nessa posio manualmente. Para isso necessrio que os pinos RS e R/W estejam em nvel alto e o bit mais significativo dos dados deve estar em nvel alto. O endereamento direto de um display de 16x2 pode ser visto na Figura 4.13.

Figura 4.13 - Endereamento direto de um display LCD 16x2.

Como o bit mais significativo dos dados deve possuir valor 1 para se posicionar o cursor na posio desejada, deve-se adicionar o valor 0x80 aos endereos anteriores. O bit mais significativo de um byte representa o valor 128, esse valor em decimal equivale a 0x80, por isso deve-se adicionar 0x80 ao valor do endereamento direto do display apresentado na Figura 4.13. O resultado dessa operao e o valor que deve ser enviado para o display, para que o mesmo posicione o cursor na posio correspondente, pode ser visto na Figura 4.14.

Figura 4.14 - Relao entre posio e valor hexadecimal que deve ser enviado ao display LCD 16x2 para posicionamento manual de cursor.

O display utilizado no projeto de 20x4, 20 colunas por 4 linhas. O valor de cada posio para posicionamento do display pode ser visto na Figura 4.15.

Figura 4.15 - Relao entre posio e valor hexadecimal que deve ser enviado ao display LCD 20x4 para posicionamento manual de cursor.

62

4.4.2.2. CONSIDERAES DE IMPLEMENTAO

A implementao do software embarcado foi feita na linguagem C (ANSI) e foram utilizadas as bibliotecas do compilador C18, que o compilador especfico da Microchip para os microcontroladores da famlia PIC 18. A seguir feita uma breve descrio das principais funes utilizadas para comunicao com o Display LCD. As funes e respectivas consideraes podem ser vistas na Tabela 4.4.

Tabela 4.4 - Descrio das principais funes do compilador C18 relacionadas comunicao com display LCD.

BusyXLCD
Descrio Biblioteca Prottipo Observaes Valor de retorno Verifica se o controlador do display LCD est ocupado xlcd.h
unsigned char BusyXLCD( void );

Essa funo retorna o status da flag de ocupado do controlador do LCD. 1, Se o controlador do LCD est ocupado; 0, Se o controlador no est ocupado.

OpenXLCD
Descrio Biblioteca Prottipo Argumentos Configura os pinos para comunicao com o display LCD e inicializa o mesmo. xlcd.h
void OpenXLCD( unsigned char lcdtype );

lcdtype uma mscara de bits formada por operaes AND com os valores de cada uma das categorias listadas a seguir:

Interface de dados: FOUR_BIT Interface de dados no modo 4 bits

63

EIGHT_BIT Interface de dados no modo 8 bits

Configurao do LCD: LINE_5X7 5x7 caracteres, linha nica do display

LINE_5X10 5x10 caracteres do display LINES_5X7 5x7 caracteres, mltiplas linhas do display Observao Essa funo configura os pinos de I/O dos microcontroladores da famlia PIC 18 para comunicarse com o controlador do display LCD. Essa funo tambm responsvel pelo processo de inicializao do display.

putcXLCD WriteDataXLCD
Descrio Biblioteca Prottipo Argumentos Envia um byte para o controlador do LCD. xlcd.h
void WriteDataXLCD( char data );

Data O dado pode ser qualquer valor de 8 bits, mas o mesmo deve ter correspondncia com a tabela de caracteres do controlador LCD.

Observao

Essa funo envia um byte de dados para o controlador do LCD. O controlador no deve estar ocupado no momento do envia dos dados, para evitar esse problema a funo BusyXLCD deve ser utilizada.

putsXLCD putrsXLCD
Descrio Biblioteca Prottipo Envia uma string para o controlador do LCD. xlcd.h
void putsXLCD( char *buffer );

64

void putrsXLCD( const rom char *buffer );

Argumentos

Buffer Porteiro para o conjunto de caracteres que devem ser enviados ao controlador LCD.

Observao

Essa funo envia uma string de caracteres apontada por buffer para o controlador LCD. O processo de transmisso finalizado quando um caractere nulo encontrado, o mesmo no transmitido. Strings localizadas na memria de dados devem utilizar a funo putsXLCD. J as strings localizadas na memria de programa, incluindo strings literais, devem utilizar a funo putrsXLCD.

WriteCmdXLCD
Descrio Biblioteca Prottipo Argumentos Envia um comando para o controlador do LCD xlcd.h
void WriteCmdXLCD( unsigned char cmd );

cmd Especifica o comando a ser enviado, podendo ser um dos pr-definidos listas a seguir:

DOFF

Desliga o display

CURSOR_OFF Ativa o display sem cursor BLINK_ON BLINK_OFF Ativa display com cursor piscante Ativa display sem piscar do cursor

SHIFT_CUR_LEFT Cursor deslocando-se para esquerda SHIFT_CUR_RIGHT Cursor deslocando-se para direita SHIFT_DISP_LEFT Display deslocando-se para esquerda SHIFT_DISP_RIGHT Display deslocando-se para direita Observao Essa funo envia um comando para o controlador do LCD. O controlador no deve estar ocupado no momento do envia dos dados, para evitar esse problema a funo BusyXLCD deve ser utilizada. 65

Alm das funes acima, tambm devem ser utilizadas algumas funes para configurao da temporizao do envio de dados para o display LCD. Essas funes so: DelayFor18TCY, DelayPORXLCD e DelayXLCD. As mesmas so utilizadas internamente pelas funes definas pelo compilador C18 para comunicao com o display LCD. A implementao dessas funes de responsabilidade do usurio, que deve garantir que as mesmas gerem um delay de 18 ciclos, 15ms e 5ms, respectivamente.

4.4.2.3. FLUXOGRAMA
O fluxograma do software embarcado para interfaceamento com display LCD pode ser visto na Figura 4.16.

Figura 4.16 - Fluxograma do "software" embarcado para interfaceamento do microcontrolador com o display LCD.

66

4.4.3. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA

O software embarcado para monitoramento de temperatura tambm uma unio dos softwares embarcados para interfaceamento com display e sensor LM 35. Logo as consideraes tericas e de implementao so as mesmas das descritas nas sees 4.4.1.1, 4.4.1.2, 4.4.2.1 e 4.4.2.2. O fluxograma desse software embarcado pode ser visto na Figura 4.17.

67

Figura 4.17 - Fluxograma do "software" embarcado para monitoramento de temperatura.

68

4.4.4. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVS DE UM SERVIDOR HTTP MICROCONTROLADO
Essa seo descreve os aspectos tericos e de implementao relacionados ao software para monitoramento de temperatura baseado em um servidor HTTP microcontrolado. So descritas, de forma breve, as principais tecnologias e recursos necessrios para implementao do software embarcado e apresentado o respectivo fluxograma.

4.4.4.1. CONSIDERAES TERICAS

Nas prximas sees so apresentadas as principais tecnologias utilizadas no desenvolvimento do software embarcado dessa seo.

4.4.4.1.1. MICROCHIP TCP/IP STACK

A pilha TCP/IP da Microchip similar a uma pilha TCP/IP tradicional. Ela foi desenvolvida levando em considerao todas as especificaes contidas nas RFCs de cada um dos protocolos que implementa, j que o objetivo da mesma permitir a conexo de microcontroladores Internet, de forma transparente, como se fosse um host qualquer, ou seja, o fato de ser um dispositivo microcontrolado e no um computador, por exemplo, no deveria ser percebido. Na Figura 4.18 pode ser vista uma representao da pilha TCP/IP da Microchip. Alguns dos servios implementados atualmente pela mesma no esto apresentados nesta figura, principalmente os servios da camada de aplicao. Assim como na especificao do modelo TCP/IP, a pilha TCP/IP da Microchip dividida em diversas camadas, como pode ser visto na Figura 4.19. A implementao de cada uma das camadas feita em arquivos separados, enquanto que os servios e a API so definidas atravs de arquivos header/include. Diferentemente do modelo de referncia TCP/IP, muitas camadas da pilha TCP/IP da Microchip acessam diretamente uma ou mais camadas que no esto necessariamente abaixo delas. A deciso de quando uma camada deve bypassar a adjacente necessria, e foi feita preliminarmente, devido quantidade de overhead e levando-se em conta se era necessrio ou no fazer um processamento pesado antes de passar para a prxima camada.

69

Figura 4.18 - Organizao da pilha TCP/IP da Microchip.

Figura 4.19 - Comparao entre a estrutura da pilha TCP/IP da Microchip e o modelo de referncia TCP/IP.

A pilha TCP/IP da Microchip chamada de pilha viva, pois algumas camadas devem estar aptas a executar algumas operaes de forma assncrona. Para permitir essa caracterstica e tambm possibilitar uma relativa independncia entre a aplicao principal e os servios utilizados pela mesma, a pilha TCP/IP da Microchip utiliza uma tcnica largamente conhecida, chamada de cooperativismo multitarefa. Em um sistema cooperativo multitarefa, h mais de uma tarefa a ser executada; onde cada uma realiza o seu processamento e retorna o controle ao programa principal e s ento a prxima tarefa fica apta a ser executada. Geralmente o cooperativismo multitarefa implementado pelo sistema operacional ou pela prpria aplicao principal. A pilha TCP/IP da Microchip foi desenvolvida para ser independente de qualquer sistema operacional e, por isso, ela implementa seu prprio mecanismo cooperativo multitarefa. Dessa forma, ela pode ser utilizada em qualquer sistema, independente se o mesmo utiliza o sistema cooperativo multitarefa ou no. De qualquer forma, uma aplicao que utiliza a pilha TCP/IP da Microchip deve tambm utilizar o mtodo cooperativo multitarefa. Isso feito atravs da diviso de um programa em mltiplas tarefas, ou organizando o programa principal como uma mquina de estados finita (FSM) e dividindo um programa grande em diversos programas pequenos.

70

A pilha TCP/IP da Microchip no implementa todos os mdulos que esto presentes em uma pilha TCP/IP tradicional. Apesar de no estarem presentes, eles podem ser implementados como uma tarefa ou mdulo separado, se necessrio. A diferena entra a pilha TCP/IP da Microchip e as demais est caracterizada principalmente na forma com que a mesma foi implementada. Em geral, as pilhas TCP/IP pressupem a presena de um sistema operacional, que o responsvel pela gerncia da mesma. No caso dos microcontroladores, a presena de um sistema operacional um fator complicador, j que os mesmos so dispositivos limitados, que trabalhavam apenas com 8 bits na poca do desenvolvimento da pilha e possuam poucas centenas de bytes de memria RAM e uma limitada memria de programa.

4.4.4.1.2. MICROCHIP FILE SYSTEM (MPFS)

O servidor HTTP, provido pela pilha TCP/IP da Microchip, utiliza um sistema de arquivos simples chamado de MPFS (Microchip File System) (MICROCHIP, 2008), para armazenar pginas WEB no microcontrolador. A imagem do sistema de arquivos MPFS pode ser armazenada na memria de programa do microcontrolador ou em uma memria externa serial do tipo EEPROM. O MPFS segue um formato especial para armazenar mltiplos arquivos em uma unidade de armazenamento. Esse formato pode ser visto na Figura 4.20.

Figura 4.20 - Formato de armazenamento utilizado pelo MPFS.

O tamanho do bloco denominado Reserved Block definido pela macro MPFS_RESERVE_BLOCK, que pode ter seu valor alterado, se o usurio assim desejar. Esse bloco reservado pode ser utilizado pela aplicao principal para armazenar dados de configurao. O MPFS inicia com um ou mais entradas MPFS FAT (File Allocation Table), seguida de um ou mais arquivos de dados. A entrada FAT descreve o nome do arquivo, localizao e seu status. O formato da entrada FAT pode ser visto na Figura 4.21.

71

Figura 4.21 - Formato da entrada FAT utilizada pelo MPFS.

A flag indica se a entrada atual est sendo utilizada, foi deletada ou est no fim do FAT. Cada entrada FAT contm 16 ou 24 bits de endereamento. O tamanho do endereamento determinado pelo tipo de memria utilizada, bem como o modelo de tamanho de memria (large ou small). Se a memria de programa interna do microcontrolador utilizada e o projeto com a pilha TCP/IP da Microchip compilado utilizando o modelo small, o endereamento de 16 bits utilizado. Se a memria de programa interna utilizada e o modelo large utilizado, o endereamento utilizado de 24 bits. Sempre que uma memria serial externa EEPROM utilizada, o endereamento de 16 bits utilizado, independente do modelo de tamanho de memria utilizado. Isso implica em uma imagem do MPFS de no mximo 64 Kb para a memria externa. O MPFS utiliza nomes pequenos para os arquivos: 8 bytes para o nome dos arquivos e 3 bytes para a extenso, por exemplo: xxxxxxxx.zzz. Um endereo de 16 bits indica o incio do primeiro arquivo do bloco de dados. Todos os nomes de arquivo so armazenados em letra maiscula para facilitar o processo de comparao dos nomes. O campo de endereo em cada entrada FAT contm uma referncia para um bloco de dados que contm os dados do arquivo em questo. O formato do bloco de dados pode ser visto na Figura 4.22. O bloco terminado com uma flag especial de 8 bits chamada EOF(End Of File), seguida do valor FFFF (para endereamento de 16 bits) ou FFFFFF (para endereamento de 24 bits). Se a parte de dados do bloco contm um caractere EOF, o mesmo preenchido por um caractere de escape.

Figura 4.22 - Formato do bloco de dados do MPFS.

72

4.4.4.1.2.1. MPFS IMAGE BUILDER

uma aplicao para PC, que pode ser utilizada para construir uma imagem MPFS, para ser armazenada no microcontrolador ou em uma memria externa serial EEPROM, a partir de um conjunto de arquivos que em geral so pginas HTML, imagens, dentre outros. Dependendo de onde a imagem MPFS ser armazenada, o usurio pode gerar um arquivo de dados em linguagem C ou um arquivo binrio que represente a imagem MPFS. A sintaxe dos comandos para utilizar o MPFS builder pode ser visto a seguir:

mpfs [/?] [/c] [/b] [/r<Block>] <InputDir> <OutputFile> Onde: /? Exibe um help na linha de comandos /c Gera um arquivo de dados em C /b Gera um arquivo binrio ( a opo padro) /r reserva um bloco de memria no inicio do arquivo (vlido apenas se o arquivo gerado binrio, o tamanho padro do bloco 32 bytes) <InputDir> o diretrio que contm os arquivos com os quais se deseja criar a imagem <OutputFile> o nome do arquivo de sada O Resultado do comando mpfs /? pode ser visto na Figura 4.23.

Figura 4.23 - Resultado do comando "mpfs /?" no utilitrio MPFS.exe

73

Por exemplo, o comando: mpfs /c <Your WebPage Dir> mypages.c gera uma imagem MPFS como um arquivo de dados, em linguagem C, chamado mypages.c, com o contedo do diretrio Your WebPage Dir. J o comando: mpfs <Your WebPage Dir> mypages.bin, gera um arquivo binrio que representa a imagem MPFS com 32 bytes de bloco reservado. O comando: mpfs /r128 <Your WebPage Dir> mypages.bin , gera o mesmo arquivo que o anterior, mas como 128 bytes de bloco reservado. Antes de a imagem ser criada, o usurio deve criar todas as pginas WEB, link-las e salvar em um nico diretrio. Se arquivos com a extenso htm so utilizados, o MPFS Image Builder retira todos os caracteres de retorno de cursor e tabulao, a fim de diminuir o tamanho da imagem gerada. Se a imagem MPFS for armazenada na memria interna do microcontrolador, o cdigo C gerado deve ser linkado com o projeto que contm a pilha TCP/IP e o programa de aplicao do usurio. Se a imagem ser armazenada em uma memria externa serial EEPROM, o arquivo binrio deve ser gravado no chip de memria EEPROM. O MPFS Image Builder no verifica limitaes de tamanho, ficando assim como responsabilidade do usurio verificar se a memria que vai ser utilizada possui capacidade de armazenar a imagem gerada.

4.4.4.1.2.2. MPFS ACCESS LIBRARY

O arquivo MPFS.c da Microchip TCP/IP Stack implementa as rotinas necessrias para acessar o dispositivo (o prprio microcontrolador ou uma memria serial EEPROM externa), que est armazenando a imagem MPFS. O usurio no precisa entender os detalhes de baixo nvel do MPFS, para poder usar recursos do servidor HTTP relacionados ao MPFS. Todos acessos ao MPFS so realizados internamente pelo servidor HTTP da pilha TCP/IP , sem a necessidade de interveno da aplicao do usurio. A verso utilizada do MPFS Access Library no permite a adio ou deleo de arquivos individuais de uma imagem existente, ou seja, todos os arquivos fazem parte de uma nica e indissocivel imagem. Qualquer mudana necessria deve acarretar a gerao de uma nova imagem com as novas caractersticas desejadas. Se a memria de programa interna do microcontrolador utilizada para armazenar a imagem MPFS, a macro MPFS_USE_PGRM deve ser definida. J se uma memria EEPROM externa utilizada, a macro MPFS_USE_EEPROM deve ser definida. Apenas uma das duas definies pode ser utilizada: em tempo de compilao essa consistncia verificada. Dependendo do tipo de dispositivo de memria utilizado, o buffer de pgina pode variar. A configurao padro do tamanho do buffer da pgina 64 bytes, sendo a mesma definida pela macro MPFS_WRITE_PAGE_SIZE no arquivo MPFS.h. Se um tamanho de buffer diferente desejado, o usurio deve alterar o valor da macro MPFS_WRITE_PAGE_SIZE. 74

4.4.4.1.3. MICROCHIP HTTP SERVER

O servidor HTTP includo na pilha TCP/IP da Microchip implementando como uma tarefa cooperativa, que co-existe com a pilha TCP/IP e a aplicao do usurio. A implementao desse servidor feita no arquivo HTTP.c, com a aplicao do usurio sendo responsvel pela implementao de duas funes do tipo callback, ou seja, funes que so chamadas automaticamente pelo servidor HTTP e que devem executar alguma tarefa a ser definida pelo usurio. Esse servidor no implementa todas as funcionalidades HTTP tpicas. Na verdade, o servidor HTTP uma implementao mnima para sistemas embarcados, que leva em considerao as caractersticas e limitaes dos mesmos. Mas, de acordo com a Microchip, o usurio pode realizar implementaes de outras funcionalidades e/ou recursos definidos pela RFC do protocolo. Algumas funcionalidades do servidor HTTP podem ser vistas a seguir:

Suporte a mltiplas conexes HTTP; Dispe de um sistema de arquivos prprio (MPFS); Suporta pginas WEB localizadas na memria de programa do microcontrolador ou em memria EEPROM serial externa; Suporta mtodo de envio GET (outros mtodos podem ser adicionados); Suporta um tipo de CGI (Common Gateway Interface) para executar funcionalidades pr-definidas a partir de um browser remoto; Suporta gerao dinmica de contedo de pginas WEB. Para integrar o servidor HTTP em uma aplicao do usurio, os seguintes passos devem ser seguidos:

Descomentar o macro STACK_USE_HTTP_SERVER no arquivo de cabealho StackTsk.h, para habilitar o cdigo do servidor HTTP; Setar a quantidade mxima de conexes que se deseja para o servidor HTTP na macro HTTP_MAX_CONNECTIONS no arquivo de cabealho StackTsk.h; Incluir os arquivos http.c e mpfs.c no projeto a ser compilado; Dependendo de onde as pginas WEB sero armazenadas, descomentar a macro MPFS_USE_PGRM ou MPFS_USE_EEPROM. Se uma memria externa EEPROM utilizada para armazenamento de dados, o arquivo xeeprom.c tambm deve ser utilizado; Modificar a funo main no programa de aplicao para incluir e inicializar os servios do servidor HTTP. O servidor HTTP usa o arquivo de nome index.htm como pgina WEB padro. Se um browser remoto acessa o servidor HTTP pelo seu endereo IP ou domnio, a pgina de nome index.htm enviada ao cliente. Dessa forma, necessrio que todas as aplicaes que 75

utilizam o servidor HTTP tenham uma pgina de nome index.htm como integrante do contedo da imagem MPFS. Se o usurio julgar necessrio, o nome da pgina padro pode ser alterada, mudando o valor da macro HTTP_DEFAULT_FILE_STRING no arquivo HTTP.c. O servidor HTTP contm uma lista com os tipos de arquivo que o mesmo suporta. Ele usa essas informaes para indicar ao browser cliente como interpretar um arquivo em particular, baseado nas trs letras que compem a extenso do arquivo. Por padro, o servidor suporta as extenses txt, htm, gif, cgi, jpg, cla e wav. Se a aplicao necessitar utilizar algum arquivo com extenso que no seja nenhuma das anteriormente citadas, o usurio deve modificar a tabela httpFiles junto com a enumerao httpContents no arquivo HTTP.c.

4.4.4.1.3.1. GERAO DINMICA DE PGINA

O servidor HTTP pode alterar pginas dinamicamente e substituir informaes em tempo-real que podem, por exemplo, se referir status das E/S do microcontrolador. Para incorporar essa capacidade de informaes em tempo-real, um arquivo CGI (*.cgi) deve conter uma string no formato %xx, onde o caractere % utilizado como cdigo de controle e xx um identificador de dois dgitos. O identificador pode ter um valor na faixa de 00-99. Quando o servidor HTTP encontra uma string no formato %xx, o mesmo remove o caractere % e faz uma chamada funo de callback HTTPGetVar. Se o usurio deseja exibir na pgina o caractere %, sem indicar automaticamente que o mesmo um caractere que deve ser interpretado como de controle, basta que se adicione outro caractere %. Por exemplo, se a informao 25% deve ser apresentada na pgina, no cdigo htm ou cgi deve ser colocado o valor 25%%. As caractersticas da funo HTTPGetVar so apresentadas a seguir:

76

HTTPGetVar uma funo de callback do servidor HTTP. Quando o servidor HTTP encontra uma string no formato %xx em uma pgina CGI que est sendo processada, o servidor executa essa funo. A mesma deve ser implementada pela aplicao do usurio e utilizada para transferir dados de uma varivel interna do microcontrolador para o HTTP. Sintaxe: WORD HTTPGetVar (Byte var, WORD ref, Byte *val)

Parmetros: var [entrada] Identificador da varivel cujo valor deve ser retornado. ref [entrada] Referncia da chamada. O valor dessa referncia indica se chamada a primeira, na instncia corrente. Aps a primeira chamada, esse valor deixa de ser pr-definido e passa a ser gerenciado pelo programa de aplicao do usurio. O servidor HTTP utiliza o valor de retorno dessa funo, para determinar se a mesma deve ser chamada novamente para obter mais dados. Como apenas um byte transferido por vez, o valor da referncia uma ferramenta que permite que a aplicao do usurio busque mais dados. Por exemplo, se o valor da varivel que se deseja obter possui mais de um byte, a aplicao do usurio pode usar a referncia como ndice para obter o contedo de um array de dados (bytes) e retorn-lo. Cada vez que um byte enviado, o valor atualizado (ou no) da referncia utilizada como retorno dessa funo, logo se a informao que se deseja retornar um array, o programa do usurio deve incrementar a referncia, apontando assim, para a prxima posio do array. Quando a aplicao enviou o ltimo byte, o programa de aplicao do usurio deve fazer com que essa funo retorne o valor da macro HTTP_END_OF_VAR como retorno da funo. O servidor HTTP continua fazendo chamadas a essa funo, at que a mesma receba HTTP_END_OF_VAR como valor de retorno. Alm da macro HTTP_END_OF_VAR, outra macro utilizada pela funo HTTP_START_OF_VAR, que o primeiro valor passado pela varivel de referncia, indicando que essa foi a primeira chamada funo, em uma determinada instncia. Logo, se a aplicao do usurio deseja retornar um array de bytes, essa macro deve ser utilizada, para que a implementao do usurio saiba o momento de inicializar o ndice da referncia e passe a indexar o array a cada nova chamada da funo. val [sada] Um byte de dados que deve ser transferido.

77

Valores de retorno: Novos valores de referncia podem ser retornados e os mesmos so controlados pela aplicao do usurio. Se o valor de retorno da funo no HTTP_START_OF_VAR, o servidor HTTP chamar a funo de novo, passando o valor antigo da varivel ref (referncia). Se o valor HTTP_END_OF_VAR retornado pela funo, isso indica ao servidor HTTP que no h mais dados a serem transmitidos e o mesmo considera a transmisso finalizada, no realizando novas chamadas a essa funo.

Observaes: Embora essa funo requisite o valor de uma varivel do programa de aplicao do usurio gravado no microcontrolador, o programa de aplicao pode no retornar um valor propriamente dito. Essa varivel pode, por exemplo, ser um array de bytes que pode ou no representar o valor de uma varivel. A informao que essa funo retorna totalmente dependente da aplicao do usurio e da pgina WEB. Por exemplo, uma varivel com identificador 50 (%50) pode representar um frame JPEG de 100 x 100 pixels. Nesse caso, a aplicao pode usar o valor de retorno como referncia para indexar o frame JPEG e retornar um byte por vez. O servidor HTTP continuar chamando a funo, at que receba HTTP_END_OF_VAR como valor de retorno dessa funo. Essa funo retorna um valor de 16 bits, logo apenas um dado de 64 Kbytes pode ser transferido como um nico valor de varivel. Se um dado possui tamanho maior, duas ou mais variveis devem ser utilizadas para aumentar a capacidade de transferncia desse array de dados.

Como a funo HTTPGetVar um pouco complexa, a seguir se apresenta um exemplo de utilizao da mesma. Suponha que tenha sido criado uma pgina chamada status.cgi que est sendo enviada pelo servidor HTTP e o contedo da mesma o seguinte:

78

<HTML> <body> <h3>Status dos leds</h3> <BR> LED 5 <h2>%05</h2> <BR> LED 4 <h2>%04</h2> <BR> LED 3 <h2>%03</h2> </body> <HTML> Durante o processamento dessa pgina, o servidor HTTP encontra a string %05. Assim que tiver realizado o processo de parsing na mesma, o servidor HTTP far a seguinte chamada callback: HTTPGetVar(5, HTTP_START_OF_VAR, &valor). Supondo que o usurio implementou a funo HTTPGetVar da seguinte forma:

WORD HTTPGetVar(BYTE var, WORD ref, BYTE *valor) {// Identificao da varivel. Verifica se a informao desejada sobre o LED5(%05) if ( var == 5 ) { // retornar 1 se o pino RB5 estiver em nvel alto, 0 caso contrrio if ( PORTBbits.RB5 ) *val = 1; else *val = 0; // Indica ao servidor HTTP que todos os dados foram transmitidos return HTTP_END_OF_VAR; } else // verifica outras variveis, por exemplo, LED4(%04) e LED3(%03) }

79

Com a implementao da funo HTTPGetVar anterior, a pgina status.cgi ser atualizada dinamicamente e em tempo real com o valor lgico presente no pino RB5 do microcontrolador. Basicamente, assim que o servidor encontrar o valor %05 na pgina status.cgi, o mesmo chamar a funo HTTPGetVar passando o identificador 5 como parmetro. No corpo da funo, verificado se o identificador 5, caso seja, o nvel lgico do pino RB5 verificado e o valor correspondente atribudo varivel apontada por val. Em seguida, a funo retorna a macro HTTP_END_OF_VAR, para indicar ao servidor que o dado foi completamente transmitido e que a funo no deve ser mais chamada para essa instncia. O valor da %05 substitudo pelo valor apontando pela varivel val e a pgina enviada para o cliente.

4.4.4.1.4. COOPERATIVE MULTITASKING

O conceito e/ou poltica de multitarefa (ANDERSON, 1999) foi introduzida pelos sistemas operacionais. Um sistema operacional dito multitarefa se capaz de dividir o uso da CPU entre vrias tarefas de forma concorrente. O conceito de cooperativo utilizado quando as prprias tarefas so responsveis por fornecer o controle da CPU para as demais. Dessa forma, uma tarefa s pode ser iniciada assim que a precedente for concluda e explicitamente atribuir o controle da CPU para a mesma. Assim, em um sistema cooperativo multitarefa, vrias tarefas cooperam para a realizao de um determinado trabalho. Em sistemas multitarefa vrias tarefas requisitam o uso da CPU, mas apenas uma tarefa pode utilizar a CPU por vez. Ento, algum mecanismo de coordenao e organizao deve ser utilizado, para garantir que cada tarefa tenha sua vez de execuo na CPU. Na prtica, cada tarefa utiliza a CPU por um intervalo de tempo curto, dando a sensao de que as tarefas esto sendo executadas paralelamente ou simultaneamente. A maioria dos sistemas microcontrolados trabalha em tempo real. Um sistema dito operar em tempo real, se o sistema pode responder a um evento no menor tempo possvel, sendo que esse tempo determinado pelo ambiente e/ou aplicao. Dessa forma, no h um tempo de resposta especfico para classificar um sistema como de tempo real ou no. Executar em tempo real no significa necessariamente que o microcontrolador deve operar em alta velocidade. O que importante em um sistema de tempo real que o mesmo responda rapidamente quando solicitado. Assim, operar em alta velocidade pode certamente contribuir para que o mesmo atinja esse objetivo. Normalmente, em um sistema microcontrolado h mais de uma atividade. Por exemplo, para monitorar temperatura trs etapas so necessrias:

Ler o valor da temperatura; Formatar o valor da temperatura; Exibir o valor da temperatura. Suponha que cada uma das tarefas acima utilize o tempo de CPU mostrado na Tabela 4.5. 80

Tabela 4.5 - Tempo de CPU hipottico para atividades necessrias para realizar o monitoramento de temperatura.

Tarefa Ler o valor da temperatura Formatar o valor da temperatura Exibir o valor da temperatura

Tempo 200ms 200ms 300ms

Se essas tarefas forem realizadas por um sistema que tambm responsvel por outras, como por exemplo, verificar o status de um boto de alarme, problemas podem acontecer. Se essas trs tarefas so executadas seqencialmente como um nico e indivisvel procedimento, significa que durante 700ms o sistema ser incapaz de realizar qualquer outra tarefa e no agir da maneira prevista se o boto de alarme for pressionado nesse intervalo. Assim, o ideal seria que houvesse um sistema operacional multitarefa, com um escalonador de processos (ou tarefas) embarcado no microcontrolador e, com capacidade de prover mecanismos de concorrncia como multithreading. Dessa forma, o escalonador escolheria de forma automatizada qual tarefa deve ser executada na CPU, de forma a garantir que todas tarefas fossem executadas e monitoradas. Alm disso, a capacidade de multithreading permitiria que um fluxo de execuo fosse responsvel pelas tarefas relacionadas temperatura e outro fluxo verificasse, em loop, o status do boto. Infelizmente, os microcontroladores ainda no possuem capacidades para permitir a implementao desses recursos, que so tpicos dos sistemas operacionais modernos. Por exemplo, se for utilizado um loop para verificar o status do boto, o microcontrolador ficar preso nesse trecho de cdigo e nunca executar as tarefas relacionadas temperatura. Utilizando o sistema cooperativo multitarefa possvel reorganizar as tarefas de forma a permitir sua execuo satisfatria. Alm disso, os microcontroladores possuem capacidade de implementar essa poltica, j que a mesma no demanda praticamente nenhum recurso de hardware adicional. Suponha que, ao invs de utilizar um nico procedimento para executar seqencialmente as trs tarefas relacionadas temperatura, seja utilizada uma mquina de estados. Alm disso, a cada execuo de uma das tarefas da Figura 4.24, o fluxo volta ao programa principal, que monitora o status do boto e depois retorna mquina de estados, para realizar a prxima tarefa e assim sucessivamente. Como conseqncia, cada tarefa ser executada de forma satisfatria e o status do boto poder ser monitorado de forma mais adequada. No pior caso, ser verificado a cada 300 ms, ao invs de 700 ms como anteriormente. Esse o mecanismo principal utilizado pela pilha TCP/IP da Microchip: um servio complexo divido em vrias tarefas, que realizam sua execuo em um tempo aceitvel e atribuem o controle da CPU para a prxima tarefa e assim sucessivamente. O servidor HTTP, por exemplo, uma mquina de estados de 21 estados.

81

Apesar de tudo, a poltica cooperativa multitarefa utilizando mquina de estados apresenta problemas. O projetista deve definir cuidadosamente o prazo de cada tarefa. Se uma tarefa demorar mais que o previsto, poder comprometer totalmente o desempenho do sistema. Caso a abordagem cooperativa multitarefa no seja suficiente ou no tenha atingido o desempenho desejado, uma possibilidade utilizar os sistemas operacionais de tempo-real (RTOS) que so uma pequena parte de cdigo armazenado no microcontrolador, que ser responsvel por controlar a alocao das tarefas, quando o microcontrolador est operando em modo multitarefa. O RTOS decide, por instncia, qual a prxima tarefa a executar, como coordenar prioridades entre as tarefas e como trocar dados e mensagens entre as mesmas.

Figura 4.24 Tarefas necessrias para o monitoramento de temperatura.

4.4.4.1.5. AJAX
O termo AJAX significa Asynchronous Javascript And XML. Ajax basicamente uma forma de usar as tecnologias Javascript e XML, a fim de tornar o navegador mais interativo com o usurio, utilizando-se para isso de requisies assncronas e outras tecnologias como HTML, CSS (Cascading Style Sheets) e DOM (Document Object Model). Na prtica, significa que possvel fazer uma requisio ao servidor, sem que seja necessrio recarregar a pgina que est sendo acessada no momento. O modelo clssico de visualizao de contedos na WEB baseado na requisio HTTP a partir do browser do cliente e na resposta do servidor atravs de uma nova pgina HTML. Esse modelo pode ser visto na Figura 4.25 (NIEDERAUER, 2007). Quando esse modelo utilizado, a cada novo dado solicitado, toda a pgina com layout e imagens recarregada, mesmo que a inteno seja exibir apenas um nmero, como o total de uma compra.

Figura 4.25 - Modelo clssico de visualizao de contedos na WEB.

82

O modelo que o AJAX prope pode ser visto na Figura 4.26 (NIEDERAUER, 2007). interessante notar que a comunicao entre o navegador e o servidor WEB no ocorre diretamente, mas por meio da ferramenta AJAX. Como o AJAX ativado por uma chamada javascript, o usurio pode continuar visualizando a pgina, enquanto ocorre a comunicao com o servidor WEB. O servidor WEB processa a solicitao AJAX, que pode ser uma pesquisa ou uma manipulao no banco de dados e envia uma resposta. Se o servidor responder com dados, o AJAX poder utilizar esses dados para fazer a atualizao de apenas uma parte da pgina que o usurio est visualizando, sem que seja necessrio recarreg-la totalmente. Caso contrrio, o usurio poder continuar interagindo com a pgina, mas a mesma no sofrer qualquer modificao visual.

Figura 4.26 - Modelo AJAX para visualizao de contedo na WEB.

O uso do AJAX muito comum em validao de formulrios, atualizao de enquetes, chats on-line via WEB, entre outras aplicaes que priorizam a comunicao em tempo real. O principal objetivo do AJAX melhorar a interatividade do usurio com o servidor, evitando interromper a interao do usurio com a pgina toda vez que a aplicao necessitar de informaes do servidor. Devido essas caractersticas, alm do AJAX ser atrativo visualmente, o mesmo economiza em recursos de banda j que a transmisso de dados bem menor, uma vez que as pginas no so recarregadas a cada nova requisio e so pginas que ainda possibilitam a obteno de informaes em tempo real. A seguir so mostradas figuras (NIEDERAUER, 2007) que possibilitam a comparao em termos de desempenho e uso de recursos de uma aplicao WEB clssica e uma aplicao com AJAX.

83

Figura 4.27 - Fluxo de dados ao longo do tempo em uma aplicao WEB clssica.

Figura 4.28 - Fluxo de dados ao longo do tempo em uma aplicao WEB com AJAX.

Figura 4.29 - Grfico comparativo dos dados transferidos ao longo do tempo entre uma aplicao WEB clssica e outra com AJAX.

84

4.4.4.2. FLUXOGRAMA
A Figura 4.30 exibe o fluxograma apenas do programa de aplicao do software embarcado para monitoramento de temperatura e disponibilizao dos dados a partir de um servidor HTTP microcontrolado. Mesmo exibindo apenas informaes sobre o software de aplicao, ainda assim alguns recursos foram abstrados a fim de evitar que o fluxograma ficasse demasiadamente extenso e complexo. Para o desenvolvimento deste software embarcado foi utilizada a verso 3.75 da Microchip TCP/IP Stack. Essa verso, apesar de antiga (ltima atualizao em 02/08/2006), a mais utilizada e a mais fiel documentao tcnica da Microchip. Alm disso, a mesma j possui um grande conjunto de funcionalidades e necessita de poucos recursos do microcontrolador, diferente das verses mais atuais. Inicialmente, feita a inicializao do hardware, que consiste na definio do pino RB7 como sada, do pino RA0 como entrada analgica e habilitao das interrupes, que so utilizadas internamente pela pilha TCP/IP. Em seguida, o conversor A/D inicializado, assim como o display LCD e so enviadas informaes para serem exibidas no display como endereo IP e MAC do circuito. Posteriormente, o temporizador inicializado, sendo utilizado para garantir os prazos das tarefas e coordenar a utilizao interna dos recursos da pilha TCP/IP. Em seguida, o sistema de arquivos MPFS e as camadas base da pilha TCP/IP so inicializadas. Logo em seguida, o servidor HTTP inicializado. Depois dos processos de inicializao do circuito, da pilha TCP/IP e do servidor HTTP. O programa entra em um loop infinito executando algumas tarefas especificas. Uma dessas tarefas piscar um led a cada segundo, como a implementao da aplicao feita utilizando a poltica cooperativa multitarefa, possvel garantir que em uma operao normal tanto do circuito quanto da pilha TCP/IP, o led piscar a cada segundo. Atravs da observao do piscar desse led possvel ter uma noo do desempenho do circuito, verificando, por exemplo, se o mesmo est operando de forma mais lenta (demorando mais de um segundo para piscar) que o previsto ou est travado (fica sempre aceso ou apagado) em alguma tarefa. As outras duas tarefas executadas, relativas ao gerenciador da pilha (Stack Manager) e servidor http, so de responsabilidade da pilha TCP/IP, bastando apenas que o usurio, a cada interao do loop, realize uma chamada das mesmas, para que suas mquinas de estados sejam atualizadas e/ou executadas. A ltima tarefa o processamento de temperatura, que consiste basicamente em ler o valor da temperatura, processar, formatar exibir no display e atualizar a varivel global, que armazena a temperatura atual, para que a mesma esteja acessvel ao servidor HTTP. Quando a funo de callback HTTPGetVar (implementada pelo usurio) chamada pelo servidor HTTP, a mesma utiliza o valor de temperatura processado anteriormente, para montar a pgina HTML de resposta ao browser do cliente. A pgina HTML gerada utiliza AJAX para apresentar a temperatura. Dessa forma, novos valores de temperatura so carregados automaticamente e em tempo real. Caso o AJAX no fosse utilizado, o usurio teria que recarregar novamente a pgina (fazendo uma nova requisio HTTP ao circuito), cada vez que quisesse ver o valor de temperatura atualizado. Um aspecto importante a ser observado no fluxograma a possibilidade de se fazer um processamento da temperatura, antes de realizar uma chamada ao servidor HTTP, de tal forma 85

que, caso uma requisio seja solicitada depois do processamento, a temperatura utilizada seria a mais atual. Entretanto, utilizou-se a ordem descrita no fluxograma a fim de dar prioridade ao processamento da pilha TCP/IP e do servidor HTTP, ficando o processamento de temperatura por ltimo. Como o loop executado continuamente em um intervalo de tempo curto, ambos modelos so intercambiveis e garantem um bom desempenho. Mas, em uma fase posterior de otimizao, essas consideraes podem ser revistas a fim de melhor o desempenho global do sistema.

86

Figura 4.30 - Fluxograma do "software" embarcado para monitoramento de temperatura e disponibilizao dos dados utilizando um servidor HTTP microcontrolado.

87

4.4.5. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVS DE UM CLIENTE TCP MICROCONTROLADO
Essa seo descreve os aspectos tericos e de implementao relacionados ao software para monitoramento de temperatura baseado em um cliente TCP microcontrolado.

4.4.5.1. CONSIDERAES TERICAS

As principais consideraes tericas para essa aplicao foram vistas nas sees 4.4.4.1.1 (Microchip TCP/IP Stack) e 4.4.4.1.3 (Cooperative Multitasking). Alm disso, o cliente TCP microcontrolado utiliza Berkelay Sockets (MATTHEW; STONES, 2007) de rede para estabelecer comunicao com um host remoto e poder disponibilizar dados de temperatura para o mesmo. Quando o sistema embarcado est utilizando o cliente TCP, pressuposto que h um host no mesmo segmento de rede com um servidor TCP esperando conexo na porta 12000. Dessa forma, o cliente TCP se conecta periodicamente ao mesmo e envia um nmero inteiro, que representa a temperatura atual monitorada pelo circuito. Para o desenvolvimento deste software embarcado foi utilizada a verso 4.55 da Microchip TCP/IP Stack. Essa verso era mais recente (ltima atualizao em 11/10/2008) no momento da implementao deste software. Essa verso foi utilizada devido a 3.75 no possuir suporte a Berkely Sockets. Ento, utilizou-se a verso 4.55 que possua esse suporte e era mais atual na poca da implementao (Fevereiro de 2009). O cliente TCP foi implementado utilizando a poltica cooperativa multitarefa. Sendo composto por quatro tarefas, que so organizadas conforme a mquina de estados descrita na Figura 4.31. A cada execuo dessa mquina de estados, uma tarefa realizada, independente do sucesso na execuo ou no, o programa volta ao fluxo de execuo do loop principal. Logo, a cada interao do loop principal, a mquina de estados do cliente TCP executada. Caso uma determinada tarefa no tenha obtido xito em sua execuo, o prximo estado da mquina mantido como o atual, para que em prximas execues a tarefa desse estado possa ser realizada com sucesso. Uma das tarefas da mquina de estados do cliente TCP exatamente a conexo ao host remoto. O estabelecimento dessa conexo dificilmente concretizado nas primeiras tentativas, logo justificvel a organizao do cliente TCP como uma mquina de estados, pois mesmo no caso de falha na tentativa de conexo, as tarefas realizadas pelos estados anteriores no so perdidas. O diagrama UML (UML, 2009) de transio de estados que descreve a mquina de estados utilizada pelo cliente TCP, implementada atravs de multitarefa cooperativa pode ser visto na Figura 4.31.

88

Figura 4.31 Diagrama UML de transio de estados do cliente TCP microcontrolado.

4.4.5.2. FLUXOGRAMA
Grande parte das etapas e/ou tarefas do cliente TCP so as mesmas do servidor HTTP microcontrolado. O processo de inicializao do circuito, a configurao do conversor A/D, a inicializao do display LCD e envio de dados, a inicializao do temporizador e do sistema de arquivos, so idnticos. Quando o fluxo de controle de execuo chega na inicializao da pilha TCP/IP, o processo muda um pouco j que alguns servios da pilha TCP/IP no so inicializados, por exemplo , o servidor HTTP. Na verdade, nem um servio nativo da camada de aplicao da pilha TCP/IP inicializado, j que nem um deles utilizado. Em seguida, o programa entra no loop infinito principal, onde permanece verificando se deve alterar o nvel lgico do led, ou seja, pisc-lo. Posteriormente, realiza o processamento da temperatura e executa a mquina de estados do cliente TCP, passando a temperatura atual como parmetro para ser enviada a um host remoto. O fluxograma do software embarcado pode ser visto na Figura 4.32.

89

Figura 4.32 - Fluxograma do "software" embarcado para monitoramento de temperatura e disponibilizao dos dados atravs de um cliente TCP microcontrolado.

90

4.4.6. SOFTWARE EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVS DE CLIENTE TCP E SERVIDOR HTTP MICROCONTROLADOS
Essa seo descreve apenas o fluxograma do software embarcado para monitoramente de temperatura atravs de cliente TCP e servidor HTTP microcontrolados. Esse software hbrido e utiliza as duas formas para disponibilizao dos dados de temperatura vistas anteriormente. Como este software basicamente uma unio dos dois programas embarcados desenvolvidos e comentados anteriormente, as consideraes tericas e de implementao so basicamente as mesmas vistas nas sees 4.4.4 e 4.4.5. Dessa forma, apenas o fluxograma que descreve a aplicao apresentado e comentado.

4.2.6.1. FLUXOGRAMA
Esse software hbrido basicamente possui todas as tarefas e funcionalidades do servidor HTTP e Cliente TCP microcontrolados em um nico software. Como conseqncia, h muito cdigo em comum aos dois softwares. Todo o processo desde o incio da aplicao at a fase de processamento de temperatura idntico. No software do servidor HTTP microcontrolado, depois de processar a temperatura, o fluxo de execuo voltaria para o incio do loop. Neste software, antes disso, a mquina de estados do cliente TCP acionada para efetuar o procedimento de envio dos dados de temperatura para um host remoto. O fluxograma desse software pode ser visto na Figura 4.33. Para o desenvolvimento deste software embarcado foi utilizada a verso 4.55 da Microchip TCP/IP Stack, j que a 3.75 no possui suporte a Berkeley Sockets. Mas como esse software hbrido, ele utiliza a verso 4.55 para o cliente TCP e alguns recursos da verso 3.75 para o servidor HTTP. As verses mais novas da pilha TCP/IP ainda dispem de cdigos legados, dessa forma, no foi um problema srio realizar essa integrao. No foi utilizado o servidor HTTP da verso 4.55 por receio de que o mesmo necessitasse de mais recursos de memria de programa e desempenho. Mas essa questo pode ser verificada em fases futuras de otimizao. Basicamente, esse software une as funcionalidades dos dois anteriores. Ou seja, ele capaz de informar a temperatura a partir de uma pgina WEB, utilizando-se para isso de um servidor HTTP microcontrolado e, tambm capaz de informar a temperatura a partir de um cliente TCP microcontrolado, de tal forma que o servidor que receber os dados poder apresentar os mesmos de uma forma mais genrica, que vai depender da necessidade e aplicao especfica do usurio.

91

Figura 4.33 - Fluxograma do "software" embarcado para monitoramento de temperatura atravs de um servidor HTTP e cliente TCP microcontrolados.

92

5. DAEMON PARA MONITORAMENTO REMOTO DE TEMPERATURA

Neste captulo so apresentadas informaes relativas ao desenvolvimento do software para monitoramento remoto de temperatura. Esse programa utilizando quando o hardware microcontrolado apresentado no Captulo 4 utilizado com o software embarcado cliente TCP. O software apresentado neste captulo responsvel por realizar a conexo via rede com o hardware microcontrolado, obter os dados de temperatura e realizar um conjunto de atividades relacionadas, que incluem: monitoramento, armazenamento e notificao de alarme. Na seo sobre consideraes tericas, inicialmente apresentado o conceito de daemon, posteriormente so feitas breves consideraes sobre programao concorrente, processos, threads, comunicao interprocessos e o conceito de excluso mtua. Em seguida, apresentada a metodologia utilizada para o desenvolvimento do software, que inclui as ferramentas e recursos utilizados. A especificao formal do software apresentada atravs dos seguintes diagramas UML 2.0 (UML, 2009): diagrama de casos de uso, diagrama de classes, diagrama de transio de estados e diagrama de atividades. Por ltimo, so feitas consideraes sobre a implementao, focando nos problemas encontrados, solues adotadas e perspectivas.

5.1. CONSIDERAES TERICAS

Essa seo apresenta as consideraes tericas relacionadas ao software desenvolvido para fazer aquisio remota de temperatura a partir de um cliente TCP microcontrolado.

5.1.1. DAEMON
Um daemon em Unix e outros sistemas operacionais multitarefa um programa que executa em background e no controlado ativamente pelo usurio. Ou seja, o programa executa como um servio e toma decises automaticamente, no necessitando de comandos do usurio para cumprir sua tarefa. Muitos sistemas operacionais iniciam daemons durante o processo de inicializao. Esses daemons, em geral, tm propsitos de responder a atividades de rede, eventos de hardware ou a outros programas. Existem convenes para os nomes de daemons, o servidor HTTP Apache, por exemplo, chamado de httpd. Mas essa nomenclatura uma mera conveno, pois o daemon principal da aplicao sendmail, por exemplo, chamado de sendmail e no de maild, como se poderia supor. Em alguns casos, os daemons precisam comunicar-se entre si. Essa comunicao em geral feita atravs de um recurso chamado sinal. Atravs do mesmo possvel comunicar-se com um daemon ou qualquer outro programa em execuo. Diversos sinais podem ser enviados, alguns com significado especfico e outros cujo significado vai depender da aplicao. 93

5.1.2. UM POUCO SOBRE PROGRAMAO CONCORRENTE

De uma forma geral, concorrncia em computao pode ser entendida como o ato de compartilhar recursos em um mesmo intervalo de tempo. Em sistemas operacionais multitarefa, por exemplo, muitos processos podem compartilhar a mesma CPU, a mesma rea de memria, os mesmos dispositivos de entrada/sada, dentre outros. Programao concorrente o estudo da execuo alternada (concorrente) de instrues atmicas de processos seqenciais (SEIXAS FILHO; SZUSTER, 2002). Instrues atmicas so instrues que o processador executa como operaes indivisveis, ou seja, a execuo das mesmas no pode ser interrompida para realizar a execuo de instrues de outro processo ou rotina de interrupo. Inclusive, so as ocorrncias de interrupes no meio de uma operao que causam os maiores problemas em programao concorrente. A programao concorrente muito mais difcil que a programao seqencial (SEIXAS FILHO; SZUSTER, 2002). Em geral, os programas concorrentes so mais difceis de serem modelados, escritos, depurados e atualizados. Em programao concorrente, no basta apenas que os programas seqenciais utilizados estejam logicamente corretos, tambm necessrio que o resultado produzido seja consistente e correto para qualquer alternncia (intercalao) nas instrues com qualquer programa em execuo, incluindo o sistema operacional. Em geral, os processos so escritos como programas seqenciais e a ordem de execuo das instrues deve ser preservada. Nos sistemas operacionais h um processo especial chamado de escalonador, que o responsvel por gerenciar e organizar a execuo dos diversos processos que desejam ser executados na CPU. A tcnica de dividir um problema em diversas tarefas (ou processos) que so executadas de forma concorrente chamada de multiprogramao (multitasking). Alm disso, um sistema produzido a partir desse paradigma chamado de multitarefas (TANENBAUM, 2007).

5.1.3. PROCESSOS
Um processo basicamente a abstrao de um programa em execuo (TANENBAUM, 2007). Atualmente, os sistemas operacionais so capazes de realizar vrias tarefas de forma concorrente: enviar um pacote pela rede, ler um arquivo armazenado no HD, enviar informaes para placa de vdeo, dentre outros. Em um sistema multitarefa, o escalonador o responsvel por executar e gerenciar o chaveamento entre os vrios processos, com relao ao uso da CPU durante um intervalo de tempo da ordem de milissegundos. Em geral, esse chaveamento to rpido que em apenas um segundo vrios programas tm sua chance de usar a CPU para sua execuo, dando a impresso de que foram executados em paralelo.

94

Figura 5.1 - Processos em um ambiente multiprogramado.

Na Figura 5.1(a) possvel ver um sistema multitasking (multitarefa) com quatro programas na memria principal. Na Figura 5.1(b) os quatro programas esto em execuo sendo caracterizados dessa forma como processos, onde cada um tem seu prprio fluxo de execuo, contador de programa lgico e executado independentemente dos demais. H somente um contador de programa fsico, ento quando um processo colocado em execuo, o seu contador de programa lgico carregado no contador de programa real para a utilizao. Na Figura 5.1(c), percebe-se que cada processo possui intervalos de tempo dedicados sua execuo e durante um intervalo de tempo apenas um processo pode ser executado. Um processo consiste basicamente do programa executvel e informaes relacionadas: dados, pilha, contador de programa, outros registradores e qualquer informao que seja necessria para sua execuo (TANENBAUM, 2007). Por exemplo, em um sistema operacional de tempo compartilhado, vrios processos compartilham uma mesma CPU e, periodicamente, o sistema operacional decide suspender a execuo de um processo e iniciar a execuo de outro, j que o primeiro teve seu tempo para utilizar o processamento da CPU. Mas, quando um processo suspenso, o sistema operacional deve garantir que o mesmo possa ser executado novamente e que a execuo se inicie exatamente no trecho em que o mesmo foi suspendido anteriormente. Logo, toda informao do processo deve ser salva em uma estrutura de dados geralmente chamada de tabela de processos. Alm disso, como no possvel estarem na memria principal do computador ao mesmo tempo todos os processos passveis de execuo, so necessrias operaes de criao e destruio dinmica de processos. Os possveis estados de um processo no sistema operacional Linux podem ser vistos na Figura 5.2 (LINUXTUTORIAL, 2009).

Figura 5.2 - Possveis estados de um processo no Linux.

95

5.1.4.THREADS
Geralmente cada processo possui um nico thread (fluxo) de controle (ou execuo) e um espao de endereamento associado. Mas, algumas aplicaes necessitam de mltiplos fluxos (threads) de execuo em um mesmo espao de endereamento e executando em alto nvel de concorrncia, quase em paralelo, como se fossem processos independentes, exceto pelo fato de possurem o mesmo espao de endereamento compartilhado. O modelo de processo visto na seo 5.1.3. baseado em dois conceitos: agrupamento de recursos e execuo. O que o modelo de thread prope exatamente a separao desses conceitos. Apesar de um thread ser associado e ter de executar em um processo, o thread e seu processo so conceitos diferentes e podem ser utilizados e tratados separadamente. Geralmente, os processos so utilizados para agrupar recursos, j os threads so as entidades escalonadas para execuo na CPU. A caracterstica principal acrescentada pelo thread ao modelo de processo capacidade de um processo possuir, atravs dos threads, mltiplos fluxos de execuo no mesmo ambiente do processo, com um grau elevado de independncia entre os fluxos (TANENBAUM, 2007). Ter mltiplos threads executando concorrentemente em um processo semanticamente anlogo a mltiplos processos executando concorrentemente em um computador. Sendo que no primeiro caso, os threads compartilham o mesmo espao de endereamento, o que na prtica significa o compartilhamento de arquivos abertos e outros recursos. J os processos compartilham o espao fsico da memria e demais recursos de hardware. Como os threads possuem algumas propriedades em comum com os processos, tambm podem ser chamados de processos leves. O termo multithread significa a existncia de mltiplos threads no mesmo processo. Na Figura 5.3 podem ser vistas duas formas de se criar trs fluxos de execuo: a) utilizando trs processos cada um com seu thread; b) utilizando trs threads de um nico processo. Na Figura 5.3(a) existem trs processos cada um com seu espao de endereamento e fluxo (thread) de execuo. J na Figura 4.3(b) existe um nico processo, ou seja, um nico espao de endereamento e trs fluxos de execuo. Logo, a diferena entre as duas situaes basicamente que, na Figura 5.3(b) os fluxos de execuo compartilham o mesmo espao de endereamento e na Figura 5.3(a) no, cada fluxo possui seu prprio espao de endereamento.

Figura 5.3 - Duas formas de se criar trs fluxos de execuo usando processos e threads.

96

Quando um processo com mltiplos threads executado, como o exemplo da Figura 5.3(b), em um sistema com uma nica CPU, os threads esperam sua vez para executar. Assim como na multiprogramao, onde a CPU alternada entre vrios processos puramente seqenciais, dando a iluso de que so executados em paralelo, o multithread possui semntica similar. Mas, nesse caso, a CPU no alterna entre processos e sim entre threads, dando a impresso que os threads esto sendo executados em paralelo. Threads distintos em um mesmo processo no so to independentes quanto processos distintos. Pois todos os threads compartilham o mesmo espao de endereamento. Na prtica, significa que eles compartilham as mesmas variveis globais e os mesmos recursos, como: arquivos abertos, sinais, processos filhos, alarmes, dentre outros. Ento se um thread abre um arquivo, o mesmo tambm fica disponvel para os demais threads desse processo. Esse fato faz muito sentido, j que a unidade de gerncia de recursos o processo e no o thread. Logo, todos recursos do processo vo estar disponveis para os threads do mesmo. Alm disso, se um thread possusse seu prprio espao de endereamento, arquivos abertos, alarmes, dentre outros, ele seria de fato um processo e no apenas um thread. A idia principal do thread compartilhar recursos para mltiplos fluxos de execuo, de tal forma a permitir que esses fluxos tenham acesso ao recurso e possam cooperar na realizao de uma determinada tarefa (TANENBAUM, 2007). Os possveis estados de um thread no sistema operacional Linux podem ser vistos na Figura 5.4 (HEIDRICH, 2009).

Figura 5.4 - Possveis estados de um "thread" no Linux.

Apesar de os threads introduzirem possibilidades interessantes de processamento concorrente, eles tambm introduzem diversas complicaes para o modelo de programao. Por exemplo, supondo que um dos cinco threads de um processo esteja em execuo e o mesmo identifique que h pouca memria disponvel e comece a alocar mais memria. No meio dessa tarefa, a CPU intercala entre os demais quatro threads, onde os mesmos constatam o mesmo fato em relao memria. Conseqncia: a memria ser alocada cinco vezes 97

desnecessariamente e isso certamente ter um custo para o sistema. Esse problema e outros similares induzidos pelo processamento multithread podem ser resolvidos, com certa complexidade, utilizando recursos de comunicao interprocessos e sincronizao.

5.1.5. PROCESSOS X THREADS

O principal fator motivador para a existncia dos threads consiste no fato de que em muitas aplicaes ocorrem mltiplas atividades de forma concorrente. Ento, a possibilidade de dividir uma aplicao em mltiplos threads, onde cada um deles responsvel pela execuo de uma atividade, realmente interessante e importante. Alm disso, os threads compartilham entre si o mesmo espao de endereamento, recursos e dados. Isso fundamental, pois em algumas aplicaes, mltiplos processos (espao de endereamento separado) no funcionariam adequadamente. Os threads so mais fceis de criar e destruir que os processos, pois tem poucos recursos associados. Mais precisamente: possuem apenas os recursos necessrios exclusivamente para que existam como cdigo executvel (BARNEY, 2009). Em muitos sistemas criar threads cem vezes mais rpido do que criar um processo (TANENBAUM, 2007). Essa propriedade muito importante, quando uma aplicao necessita criar e destruir threads dinamicamente e em um intervalo de tempo curto. Na Figura 5.5 pode ser observada uma comparao na criao de threads e processos, utilizando recursos de um sistema operacional baseado em Unix (BARNEY, 2009). Nesse teste, foi realizada a criao de 50.000 threads e processos. Para criao de threads foi utilizada a funo pthread_create da biblioteca Pthread e para criao de processos foi utilizada a chamada de sistema fork. Para anlise do parmetro de desempenho foi utilizada a ferramenta time para profiling, que est presente em grande parte dos sistemas baseados em Unix. A ferramenta time fornece o tempo de execuo, em segundos, de um programa baseado em trs parmetros: real tempo total utilizado pela aplicao, desde sua execuo at a finalizao; user o tempo de CPU gasto pelo processo; sys o tempo gasto pelo sistema para preparar em kernel mode a execuo do programa: carregar, mover o cdigo e iniciar a execuo.

Figura 5.5 - Comparao em termos de tempo para criao de "threads" e processos.

De acordo com (TANENBAUM, 2007), o uso de threads no resulta necessariamente em ganho de desempenho, quando todos eles so orientados a CPU. Mas quando h um grande 98

nmero de processamento (computao) e de operaes de entrada/sada, o uso de thread aumenta o desempenho da aplicao, j que essas atividades sero sobrepostas: enquanto uma parte delas est operando entrada/sada, as outras esto executando operaes na CPU.

5.1.6. COMUNICAO INTERPROCESSOS

muito comum que processos necessitem se comunicar. Por exemplo, um determinado processo pode necessitar do resultado gerado pelo processamento de outro. Logo, a necessidade de comunicao entre processos existe e deve ser feita de uma maneira estruturada e sem interrupes para evitar inconsistncias. As informaes apresentadas nessa seo tambm valem para threads. Dois dos principais assuntos abordados pela comunicao interprocessos so as condies de disputa e regies crticas. As definies desses dois termos podem ser observadas a seguir: Condies de disputa: situaes nas quais dois ou mais processos esto lendo e/ou escrevendo algum dado em uma memria compartilhada, cujo resultado final depende das informaes de qual processo efetuou operaes e quando executou precisamente. Regies crticas: parte do programa onde h manipulaes de uma memria compartilhada.

5.1.6.1. EXCLUSO MTUA

Dois ou mais processos que operam de forma concorrente sobre uma regio crtica esto sujeitos a condies de disputa. O ideal para resolver o problema seria o acesso regio critica ser realizado por instrues atmicas, mas essa soluo de difcil implementao. possvel desenvolver programas que operam de forma concorrente e intercalada sobre uma regio no crtica e quando operam em uma regio crtica tem suas instrues executadas de forma indivisvel, como se fossem uma nica instruo atmica. Se um determinado programa com processos concorrentes garante que apenas um processo est executando em uma determinada regio crtica, se diz que o mesmo est operando garantindo excluso mtua. Regio crtica tambm pode ser definida como um trecho de um programa que deve ser executado sob excluso mtua, e regio crtica o trecho do programa que, por definio, executado sob excluso mtua (SEIXAS FILHO; SZUSTER, 2002). Em programao concorrente deve-se modelar e definir uma forma organizada para entrar e sair da regio crtica, de forma que apenas um processo possa entrar na mesma por vez e, assim que sair, avisar os demais que a regio crtica est novamente liberada para o acesso. De certa forma, o que est sendo feito apenas serializar o acesso regio crtica. Caso um 99

processo tente acessar a regio crtica enquanto outro est executando, o primeiro deve ficar esperando at que a mesma seja liberada. Basicamente quatro condies devem ser satisfeitas para se operar de forma correta, consistente e satisfatria sobre uma regio crtica:

Nunca dois processos podem estar simultaneamente em uma mesma regio crtica; Se apenas um processo deseja entrar em sua regio crtica, ele dever fazer com o mnimo de overhead; Nenhum processo executando fora de sua regio crtica pode bloquear outros processos; Nenhum processo deve esperar eternamente para entrar em sua regio crtica. Os principais mecanismos de programao concorrente para coordenar o acesso a regies crticas e possibilitar comunicao interprocessos so:

Semforo: uma varivel especial que tem como objetivo permitir o acesso a regies crticas em ambientes multiprogramados. So efetuadas duas operaes padres nos semforos: Wait ou P decrementa o valor do semforo. Se o semforo possui valor zero, o processo colocado para dormir; Signal ou V se o semforo possui valor zero e existir algum processo dormindo, um processo ser acordado. Caso contrrio, o valor do semforo incrementado. O valor inicial de um semforo indica quantos processos podem ter acesso regio crtica. Mutex: uma varivel especial que pode estar em apenas dois estados: travado ou liberado. Assim como os semforos, os mutexes so adequados para gerenciar o acesso a recursos compartilhados garantindo excluso mtua. Os mutexes podem, inclusive, ser implementados com semforos binrios, ou seja, semforos que podem apenas assumir dois valores 0 ou 1 e que, conseqentemente, permitem acesso de um nico processo regio crtica. So permitidas duas operaes nos mutexes: lock e unlock. Quando um processo deseja acessar sua regio crtica ele executa um lock. Dessa forma, qualquer outro processo que tentar entrar na regio crtica nesse momento ser automaticamente bloqueado e permanecer nesse estado, at que o processo na regio crtica termine e chame a operao unlock, liberando assim a regio crtica para acesso. Monitor: uma unidade bsica de sincronizao de alto nvel. Um monitor uma coleo de procedimentos, variveis e estrutura de dados, agrupadas em um tipo especial de mdulo ou pacote. Os processos podem executar procedimentos do monitor quando quiserem, mas no podem acessar diretamente, a partir de procedimentos declarados externos ao monitor, as suas estruturas internas de baixo nvel. Os monitores apresentam uma caracterstica importante para garantir excluso mtua: somente um nico processo pode estar ativo no monitor em um dado momento. Os monitores so construes de 100

linguagem de programao e, portanto, os compiladores ou interpretadores sabem que eles so especiais e tratam de forma diferenciada chamadas aos procedimentos do monitor. Se um processo deseja executar um procedimento do monitor, inicialmente verificado se h algum outro processo executando no monitor. Se houver, o processo que chamou o procedimento ser suspenso, at que o outro processo termine a execuo no monitor. Basicamente, com um modelo de concorrncia baseado em monitores, os mecanismos de tratamento de excluso mtua so transparentes para o programador, ou seja, o mesmo no mais responsvel pelo gerenciamento (bloqueio e desbloqueio) manual da regio crtica, como no caso do semforo e Mutex. Troca de mensagens: esse mtodo de comunicao interprocessos utiliza duas operaes, send e receive, que assim como os semforos e diferente dos monitores, so chamadas de sistema e no recursos de uma determinada linguagem de programao. A operao send utilizada para enviar um dado para outro processo e receive recebe um dado de outro processo. O mecanismo de troca de mensagem pode ser utilizado para comunicao entre processos de uma mesma mquina ou em mquinas distintas que esto conectadas via rede. Em alguns sistemas operacionais, a troca de mensagens transparente, independentemente se os processos esto sendo executados em uma mesma mquina ou em mquinas distintas conectadas por uma rede.

5.2. METODOLOGIA
O software para aquisio remota de dados de temperatura foi desenvolvido em C/C++. Basicamente, um programa orientado a objetos dividido em diversas classes. Alguns trechos foram implementados em C puro, esses trechos esto relacionados a recursos de baixo nvel de sistemas operacionais baseados em Unix , como: threads, Mutex, sinais, alarmes, sockets, dentre outros. Especialmente os threads foram encapsulados em classes C++, de forma que os threads do software de monitoramento so basicamente classes C++ que estendem a classe thread desenvolvida. Os theads e mutex utilizados so definidos pelo padro IEEE POSIX 1003.1c tambm conhecidas como POSIX Threads ou PThreads (YOLINUX, 2009). J os sinais (signal) utilizados so os padres disponveis nos sistemas derivados do Unix, como o Linux. Para o mecanismo de comunicao remota foram utilizados os Berkeley sockets de rede. Alm disso, a API em linguagem C do MySQL (MYSQL, 2009) foi utilizado pelo software de monitoramento para fazer inseres e recuperaes de dados armazenados no banco de dados. Na prxima seo so apresentadas algumas ferramentas utilizadas para o desenvolvimento do software de monitoramento e tambm alguns recursos utilizados pelo mesmo.

101

5.2.1. ECLIPSE IDE CDT

Eclipse IDE (ECLIPSE, 2009) um IDE (Ambiente de desenvolvimento integrado) de cdigo livre para o desenvolvimento de software. O Eclipse foi desenvolvido inicialmente pela IBM e hoje um dos IDE Java mais utilizados no mundo. O Eclipse CDT uma verso do Eclipse IDE para o desenvolvimento em C/C++. O Eclipse CDT dispe dos seguintes recursos: suporte para criao e gerenciamento de projetos, utilitrio make incluso, editor de cdigo, hierarquia de cdigo, grafo de chamadas, sintaxe highlighting, ferramentas de busca, auto-completar, refatoramento e gerao de cdigo, integrao com diversos compiladores C/C++, depurao visual com a possibilidade de visualizar registradores, memria e disassembly, dentre outros recursos. O logo do projeto Eclipse CDT pode ser visto na Figura 5.6 e algumas telas do Eclipse CDT podem ser vistas na Figura 5.7.

Figura 5.6 - Logo do projeto Eclipse IDE CDT.

Figura 5.7 - Algumas telas do Eclipse IDE CDT.

102

5.2.2. MYSQL
um SGBD (Sistema Gerenciador de Banco de Dados) que utiliza a linguagem SQL (Structured Query Language) como linguagem de consulta. atualmente um dos bancos de dados mais populares e utilizados. O logo do MySQL pode ser visto na Figura 5.8. Algumas das caractersticas do MySQL so:

Portabilidade (suporte a grande maioria dos sistemas operacionais modernos); Compatibilidade (existem diversos drivers e APIs para comunicao com diversas linguagem de programao); Excelente desempenho e estabilidade; Baixa exigncia de recursos de hardware; Tabelas hash em memria que so usadas como tabelas temporrias; Um sistema de privilgios e senhas que muito flexvel, seguro e que permite verificao baseada em estaes/mquinas. As senhas so seguras porque todo o trfego de senhas criptografado durante a conexo ao servidor; Suporte total a multithread, usando threads diretamente no kernel; Facilidade de uso; um Software Livre com base na licena GPL (General Public License); Permite a utilizao de vrios Storage Engines como MyISAM, InnoDB, Falcon, BDB, CSV, dentre outros; Suporta controle transacional; Suporta Triggers; Suporta Stored Procedures e Functions; Replicao facilmente configurvel; Possui diversas ferramentas para gerenciamento atravs de interface grfica.

Figura 5.8 - Logo do SGBD MySQL.

5.2.3. POSIX THREADS

um padro POSIX (Portable Operating System Interface) para threads, que define uma API padro para criao e manipulao de threads. As bibliotecas que implementam as threads POSIX so chamadas Pthreads, so muito utilizadas em sistemas Unix e seus derivados como o Linux.

103

5.2.4. BERKELEY SOCKETS

O Berkeley Sockets uma API genrica para programao baseada em protocolos de comunicao orientados a conexo, como TCP e orientados a datagrama, como UDP. A implementao das chamadas de sistema dessa interface so padronizadas em todos sistemas operacionais Unix e estende-se para muitas outras plataformas. A padronizao da interface para sockets foi feita originalmente no escopo do sistema operacional chamado Unix BSD (Berkeley Software Distribution), por isso eles so chamados de Berkeley Sockets.

5.2.5. POSTFIX
O Postfix um agente para transferncia de e-mails ou MTA (Mail Transfer Agent) baseado no protocolo SMTP (Simple Mail Transfer Protocol), popularmente conhecido como servidor de e-mails. O Postfix um software livre. Dentre suas caractersticas principais esto: facilidade na administrao, velocidade, segurana e compatibilidade com o sendmail, que um dos servidores de e-mails mais famosos e poderosos do mundo Unix (POSTFIX, 2009). O logo do Postfix pode ser visto na Figura 5.9.

Figura 5.9 - Logo do servidor de e-mail Postfix.

5.2.6. DEBIAN 4 ETCH

Debian simultaneamente o nome de uma distribuio no comercial livre (gratuita e de cdigo fonte aberto) de GNU/Linux e de um grupo de voluntrios que o mantm (DEBIAN, 2009). Como o Debian fortemente baseado no projeto GNU (GNU is Not Unix), geralmente chamado Debian GNU/Linux. O Debian especialmente conhecido pelo seu sistema de gerenciamento de pacotes, chamado APT (Advanced Packaging Tool), que permite: atualizaes fceis a partir de verses antigas, instalaes facilitadas de novos pacotes e remoes completas dos pacotes antigos. O logo do Debian pode ser visto na Figura 5.10.

Figura 5.10 - Logo do sistema operacional Debian/Linux.

104

5.3. ESPECIFICAO
Nessa seo so apresentados alguns diagramas UML 2.0, que descrevem as caractersticas, requisitos e funcionamento do software para monitoramento desenvolvido chamado de JDaemon. Os diagramas UML utilizados so: diagrama de casos de uso, diagrama de classes, diagrama de transio de estados e diagrama de atividades.

5.3.1. DIAGRAMA DE CASOS DE USO

Na Figura 5.11 pode ser visto o diagrama de casos de uso do JDaemon. O sistema embarcado (especificado no Captulo 4) utilizando o software embarcado cliente TCP modelado como um ator e interage diretamente com os casos de uso Estabelecer conexo remota e Receber temperatura. Assim que o sistema embarcado conecta-se ao JDaemon, o mesmo envia um dado de temperatura. Logo em seguida, o JDaemon pode executar os casos de uso Disparar alarme ou Realizar amostragem da temperatura. Se o caso de uso Disparar alarme executado, obrigatoriamente os casos de uso Registrar em banco de dados, Registrar em arquivo de LOG e Enviar notificao de alarme por E-mail tambm o so. J se o caso de uso Realizar amostragem de temperatura executado, apenas os casos de uso Registrar em banco de dados e Registrar em arquivo de LOG so obrigatoriamente executados. Uma observao importante que os casos de uso Disparar Alarme e Realizar amostragem da temperatura possuem uma semntica de relao ou - exclusivo, ou seja, apenas um deles pode ser executado por vez.

105

Figura 5.11 - Diagrama de casos de uso do JDaemon.

5.3.2. DIAGRAMA DE CLASSES

Na Figura 5.12 pode ser visto o diagrama de classes do JDaemon. Inicialmente, foi criada classe JThread que encapsula os recursos de uma thread do padro POSIX (Pthread). Basicamente, no escopo do JDaemon para se criar um thread basta que se crie uma classe que estenda JThread e implemente o mtodo virtual puro run. O trecho de cdigo implementado no mtodo run ser o trecho que executar de forma concorrente. Foram criadas trs classes JThread: JThreadAlarme, JThreadLOG e JThreadBanco. A primeira responsvel pela notificao de alarmes de temperatura, a segunda responsvel por fazer amostragem de temperatura e armazenar em um arquivo de LOG e a ltima responsvel por fazer a mesma amostragem, mas utilizando um banco de dados. No pacote Recursos Unix so apresentados os recursos tpicos de sistemas Unix que foram utilizados na implementao do JDaemon. Apesar de esses recursos serem apresentados no diagrama como classes, eles so recursos de baixo nvel do Unix implementados C e, portanto, tipicamente procedurais. Os recursos do pacote Unix utilizados foram: sockets, alarm e mutex. Como dito anteriormente, esses recursos so implementados em C pelos

106

sistemas Unix, mas a forma com que foram apresentados no diagrama de classes pode ser utilizada como sugesto para encapsul-los em classes. A classe JDaemon representa o daemon propriamente dito. Ela utiliza todas as classes apresentados no diagrama e sua existncia completa s faz sentido se essa condio for satisfeita. Portanto, o relacionamento entre o daemon e as demais classes foi modelado como uma composio (agregao forte). Todas as classes do JDaemon fazem parte de um namespace chamado JDaemon. O recurso namespace similar ao package (pacote) da linguagem Java, mas o pacote Java armazena classes e o namespace pode armazenar funes, classes, variveis globais, constantes, estruturas (struct), dentre outros.

Figura 5.12 - Diagrama de classes do JDaemon.

107

5.3.3. DIAGRAMA DE TRANSIO DE ESTADOS

Na Figura 5.13 pode ser visto o diagrama de transio de estados simplificado do JDaemon. Inicialmente, o mesmo est no estado inicializando. Logo em seguida passa para o estado esperando conexo e permanece neste at que o hardware microcontrolado se conecte ao mesmo. Aps a conexo ser estabelecida, o JDaemon vai para o estado recebendo temperatura e fica no mesmo, at que a temperatura tenha sido enviada pelo cliente remoto (hardware microcontrolado). Assim que a temperatura recebida, verificado se o valor da mesma est dentro dos limites permitidos. Caso no esteja, o estado verificando se o alarme deve ser registrado executado e o mesmo define se o thread de alarme deve ser criado e executado ou se o alarme deve ser descartado, a fim de receber um evento de alarme mais atual ou significativo. Se o thread de alarme criado, o mesmo executa seqencialmente os estados registrado alarme em arquivo de LOG, registrando alarme em banco de dados e enviando notificao de alarme por e-mail. Caso o valor da temperatura esteja dentro dos limites aceitveis, o JDaemon vai para o estado habilitando amostragem. Se j houve um estouro no temporizador de amostragem, o prximo estado executado o criando Threads de Registro, que cria os threads para armazenar a temperatura no arquivo de LOG e no banco de dados, onde cada um executa o estado relativo sua funcionalidade. Caso no tenha havido um estouro no temporizador de amostragem, significa que ainda muito cedo para registrar valores, ento o JDaemon vai para o estado recebendo temperatura novamente a fim de receber uma temperatura mais atual para armazenar no prximo estouro do timer de amostragem. Assim que receber uma nova temperatura, se a mesma estiver nos limites aceitveis, a amostragem j estiver sido habilitada e j tiver ocorrido um estouro no temporizador de amostragem, o JDaemon vai diretamente para o estado criando threads de registro. Um detalhe importante da implementao do JDaemon pode ser observado na transio de sada do estado criando threads de registro. Alm do fluxo (thread) principal so criados outros dois fluxos (threads) alternativos. Isso importante, porque o fluxo principal retorna imediatamente para o estado esperando conexo, a fim de estabelecer uma nova conexo e receber um novo dado de temperatura. Dessa forma, enquanto os dois threads ainda esto executando suas atividades, o thread principal j est monitorando a temperatura novamente e pode responder o mais rpido possvel ocorrncia de uma alarme. Nessa situao fica bem perceptvel o poder da programao multithread.

108

Figura 5.13 - Diagrama de transio de estados do JDaemon.

5.3.4. DIAGRAMA DE ATIVIDADES

Na Figura 5.14 pode ser visto o diagrama de atividades simplificado do JDaemon. Algumas operaes foram abstradas para simplificar o diagrama. Inicialmente realizada a inicializao dos recursos utilizados pelo JDaemon: estruturas de dados, variveis globais, mutex, alarm e sockets. Posteriormente, o mesmo fica esperando conexes TCP em uma porta especfica. Assim que um cliente TCP (mais precisamente o hardware microcontrolado) realiza a conexo, o mesmo disponibiliza um dado de temperatura. Ento, o JDaemon verifica se o valor do dado est dentro dos limites aceitveis. Caso esteja, ele verifica se o tempo de amostragem j foi estabelecido. Em caso positivo, so criados dois threads para executarem a atividade de registro de temperatura no arquivo de LOG e no banco de dados, de forma concorrente. Caso a temperatura no esteja dentro dos limites definidos, um thread de alarme criado e o mesmo fica responsvel por enviar um e-mail para o administrador do sistema, notificando o alarme e tambm por registrar a ocorrncia do alarme no banco de dados e no arquivo de LOG. 109

O acesso aos recursos compartilhados gerenciado por duas regies crticas: uma para acesso ao arquivo e outra para o banco de dados. Isso necessrio devido o JDaemon criar threads que utilizam recursos compartilhados, sendo possvel inclusive que dois ou mais threads tentem acessar o recurso de forma concorrente gerando assim inconsistncias. Em relao ao banco de dados, o tratamento de excluso mtua foi feito mais especificamente para a abertura/fechamento da conexo com o banco de dados. Caso um thread tente utilizar o arquivo ou banco de dados e no consiga, uma notificao de erro registrada no outro recurso. Por exemplo, se houve uma falha na abertura do arquivo, o registro da falha feito no banco de dados. Dessa forma, a falha pode ser registrada utilizando a redundncia do registro de informaes. Caso fosse utilizada s uma fonte de registro (arquivo ou banco de dados), isso no seria possvel. As aes de registro de erro de abertura do arquivo ou conexo com o banco de dados so descritas como atividades simples para diminuir o diagrama, mas elas tambm necessitam de um conjunto de aes (ou atividades) para sua realizao. Diversos esteretipos foram utilizados na tentativa de facilitar a compresso do diagrama. As atividades que so executadas por um thread especfico podem ser identificados pelo esteretipo ThreadX, onde X pode ser Alarme, Banco ou LOG. Dessa forma, cada atividade (ou ao) do diagrama apresentada de forma relacionada ao thread que a executa. As operaes lock e unlock das variveis mutex, que gerenciam o acesso a uma regio crtica, so representadas como esteretipo, associadas tambm a que recurso compartilhado as mesmas esto gerenciando: arquivo ou banco de dados.

110

Figura 5.14 - Diagrama de atividades do JDaemon.

111

5.4. IMPLEMENTAO
O software para aquisio remota de temperatura (JDaemon) foi desenvolvido para ser um daemon (seo 5.1.1), ou seja, um programa que executa como um servio e toma decises automaticamente sem a interveno do usurio. O mesmo foi programado utilizando as linguagens C/C++, majoritariamente orientado a objetos e utiliza alguns recursos POSIX, que so programados em C originalmente. A linguagem C/C++ foi escolhida por questes de desempenho e suporte a recursos POSIX. Para estabelecer conexo remota foram utilizados os Berkeley Sockets (seo 5.2.4), que so um exemplo de implementao do mecanismo de troca de mensagens (seo 5.1.6.1) para comunicao interprocessos (seo 5.1.6). O JDaemon atua como um servidor TCP, que espera conexes remotas em uma porta especifica. Para registro de informaes foram utilizados arquivos de LOG e o banco de dados MySQL 5.0 (seo 5.2.2), a fim de garantir redundncia e uma maior confiabilidade no registro das informaes. Caso haja problema em um dos mecanismos de armazenamento, o outro pode ser utilizado para completar a atividade. O JDaemon um programa que utiliza mltiplos fluxos de execuo para realizao de suas atividades. Para implementar essa caractersticas foram utilizados threads (seo 5.1.4) ao invs de processos (seo 5.1.3), pois os mesmos utilizam menos recursos e so mais adequados para serem criados e destrudos dinamicamente (seo 5.1.5). O sistema operacional especificado para executar o JDaemon o Debian 4 Etch (seo 5.2.6), um sistema operacional multitarefa que possui suporte a threads. Logo, o JDaemon foi implementado para ser multithread sendo capaz de executar atividades de forma concorrente. Para isso, o daemon utiliza POSIX Threads (5.2.3), encapsulados em uma classe C++ chamada JThread, que possui o mtodo virtual puro run. Cada classe que deseje executar em thread deve estender a classe JThread e implementar o mtodo run, que o mtodo executado de forma concorrente. Encapsular em uma classe um recurso de baixo nvel implementado em C como as pthreads no foi simples e teve um custo muito caro em termos de tempo e depurao. Alm disso, a classe ofstream da biblioteca fstream.h, que a classe padro C++ para escrita em arquivo, talvez por incompatibilidade, no pde ser utilizada com sucesso para abrir um arquivo dentro do mtodo run de uma classe JThread, que um POSIX thread cuja implementao original em C. Ento, as funes da biblioteca stdio.h da linguagem C para manipulao de arquivos foram utilizadas ao invs das classes C++. Para conexo com o bando de dados MySQL 5.0 foi utilizada a API em C, ao invs da C++, para evitar problemas como o mencionado anteriormente. Como o arquivo de LOG e banco de dados podem ser acessados de forma concorrente pelos mltiplos threads criados pelo JDaemon, os trechos de cdigo relativos a operaes com o banco de dados e arquivo de LOG so regies crticas e representam recursos compartilhados entre os vrios threads. Logo, as operaes nessas regies crticas devem ser realizadas de forma atmica, para garantir excluso mtua no acesso aos recursos. Para garantir excluso mtua foi utilizado o tipo mutex da biblioteca pthread.h (POSIX Thread), que exemplo do mecanismo de sincronizao Mutex (seo 5.1.6.1) ou semforo binrio (seo 5.1.6.1). 112

Apesar de o JDaemon receber informaes em intervalos de tempo muito pequenos, na ordem de segundos. O mesmo no armazena todas essas informaes, a fim de evitar o excesso e redundncia de dados no arquivo de LOG e no banco de dados. Os dados de temperatura so recebidos a cada 10 segundos, por exemplo, so analisados e se o valor for abaixo do limite aceitvel, o thread de alarme ativado para armazenar o dado no banco e no arquivo de LOG e enviar um e-mail com a notificao de alarme para o administrador do sistema. Caso a temperatura esteja no nvel aceitvel, a mesma descartada at que o intervalo para amostragem de temperatura tenha sido estabelecido. Nessa situao dois threads so criados, um para armazenar dados no arquivo e outro para armazenar os dados no banco. Esse esquema de amostragem baseado em estouro de temporizador foi implementado utilizando o sinal (signal) de alarme (alarm) disponvel em sistemas derivados do Unix. O alarme ativado com um tempo pr-determinado e, a cada estouro, a amostragem de temperatura habilitada. O JDaemon foi implementado de forma a garantir que um evento de alarme iniba a execuo dos threads de amostragem da temperatura, j que o thread de alarme j faz o registro de temperatura no banco de dados e no arquivo de LOG. Alm dos registros, o thread de alarme responsvel por enviar um e-mail para o administrador do sistema, utilizando para isso o Postfix (seo 5.2.5). Problemas de registro excessivo de dados tambm podem ocorrer no registro do alarme. Assim que a ocorrncia de alarme identificada, verifica-se se a temperatura atual menor que a temperatura anterior subtrada de um erro predefinido. Se for, ela deve ser registrada. Seno, deve ser verificado se o evento de alarme relativo a uma nova ocorrncia ou ainda est no escopo da anterior e para isso utilizado um temporizador. Quando o temporizador estoura, significa que o evento pode ser considerado uma nova ocorrncia, ou seja, se passaram 10 minutos em relao ao evento anterior, por exemplo. O thread de alarme faz muitas atividades de forma seqencial: escreve no arquivo, no banco de dados e envia um e-mail. Por que no criar um thread para cada uma dessas atividades? De fato uma idia interessante e completamente possvel. Entretanto, criar muitos threads dentro de outro thread pode ser uma fonte inicial de problemas de desempenho. Ento, a implementao atual foi feita da forma mais conservadora possvel. De qualquer forma, o JDaemon foi organizado e implementado de forma a permitir que melhorias desse tipo possam ser feitas. Por esse motivo existe uma classe JThread genrica, que permite que novos threads sejam criados a partir dela.

113

6. SISTEMA WEB PARA MONITORAMENTO DE TEMPERATURA

Neste captulo so apresentadas informaes relativas ao desenvolvimento do sistema WEB. Esse software utilizado para possibilitar que as informaes de temperatura, armazenadas no banco de dados pelo JDaemon(Captulo 5), possam ser apresentadas atravs de grficos e relatrios. Alm disso, atravs do sistema WEB, essas informaes podem ser acessadas atravs da Internet. Na seo sobre as consideraes tericas, inicialmente so apresentados alguns aspectos da linguagem Java relevantes a esse projeto, como a plataforma JEE e alguns de seus componentes (Servlets, JSP e JSTL), que foram utilizados no sistema em questo. Em seguida, explicado o conceito de JavaBean, o padro MVC para arquitetura de software e a arquitetura em trs camadas. Posteriormente, apresentado de forma breve o conceito de padres de projeto, bem como os padres clssicos, que so apresentados divididos nas categorias: padres estruturais, de criao e comportamentais. Em seguida, os padres de projeto utilizados no sistema WEB so apresentados com mais detalhes. Na seo de metodologia so apresentadas as ferramentas e tecnologias utilizadas. Por fim, a especificao do sistema apresentada, atravs de um diagrama de casos de uso e de trs diagramas de classe, que descrevem a arquitetura lgica do sistema de forma incremental. Ou seja, cada diagrama possui melhorias e novas caractersticas em relao ao anterior.

6.1. CONSIDERAES TERICAS

Essa seo apresenta as consideraes tericas relacionadas ao sistema WEB desenvolvido, para possibilitar o monitoramento de temperatura a partir da Internet.

6.1.1. JAVA
Java (JAVA, 2009) uma linguagem de programao orientada a objetos, desenvolvida pela Sun Microsystems (SUN, 2009). Uma das particularidades do Java que, diferente das linguagens convencionais que so compiladas para cdigo de mquina, o Java compilado para um cdigo intermedirio, chamado de bytecode, que executado por uma mquina virtual. Algumas das principais caractersticas do Java so: Orientao a objeto - Baseado no modelo de Smalltalk, Simula67 e C++; Portabilidade - Independncia de plataforma; Recursos de Rede - Possui extensa biblioteca que facilita a utilizao com protocolos TCP/IP, como HTTP e SMTP; Segurana - Pode executar programas via rede com restries de execuo; distribuda com um vasto conjunto de bibliotecas (ou APIs); 114

Possui facilidades para criao de programas distribudos e multitarefa; Desalocao automtica de memria, atravs de coletor de lixo (garbage collector); Carga Dinmica de Cdigo - Programas em Java so formados por uma coleo de classes armazenadas independentemente e que podem ser carregadas no momento de utilizao.

6.1.1.1. JAVA EE
A Java EE (Enterprise Edition) uma plataforma de software utilizada para o desenvolvimento de aplicaes distribudas utilizando a linguagem Java (JAVAEE, 2009). A plataforma JEE (JAVAEE, 2008) oferece um conjunto de bibliotecas, que disponibilizam funcionalidades para o desenvolvimento de software multicamada, distribudo, tolerante a falha, baseado em mdulos e que pode ser executado via WEB. O conjunto de APIs fornecidas pelo JEE pode ser vista na Figura 6.1 (JAVAEE, 2008) dividida em seus respectivos container.

Figura 6.1 - APIs fornecidas pela plataforma JEE.

A plataforma JEE utiliza um modelo multicamada distribudo para aplicaes coorporativas (enterprise). A lgica da aplicao dividida em componentes de acordo com sua funo, e vrios componentes da aplicao podem ser instalados em mquinas diferentes, dependendo da camada da plataforma JEE que o componente da aplicao pertence. Na Figura 6.2. (JAVAEE, 2008) podem ser vistas duas aplicaes JEE multicamadas divididas nas camadas descritas a seguir: 115

Client-tier: componentes que executam na mquina do cliente; Web-tier: componentes que executam em um servidor JEE; Business-tier: componentes que executam em um servidor JEE; Enterprise information system (EIS)-tier: software que executa em um servidor EIS. Programas do tipo SGBD (Sistema Gerenciador de Banco de Dados) e de processamento de transaes so exemplos de servios que executam em um servidor EIS.

Figura 6.2 - Dois exemplos de aplicaes JEE multicamadas.

Apesar de uma aplicao JEE poder consistir de trs ou quatro camadas como foi apresentado na Figura 6.2 (JAVAEE, 2008), aplicaes JEE multicamadas geralmente so consideradas do tipo trs camadas fsicas, j que so distribudas em trs localizaes: mquinas cliente, mquinas servidoras JEE e banco de dados ou mquinas de transao. Aplicaes trs camadas que executam dessa forma estendem o modelo padro cliente-servidor de duas camadas colocando um servidor de aplicao multicamada entre a aplicao cliente e a camada de persistncia. No escopo desse trabalho, apenas os componentes do Web Container foram utilizados. Os componentes WEB do JEE providenciam extenso dinmica das capacidades do servidor WEB. Esses componentes podem ser Java Servlets (seo 6.1.1.1.1), pginas JSP (6.1.1.1.2) ou servios WEB do tipo endpoint. A interao entre um cliente e uma aplicao WEB pode ser vista na Figura 6.3 (JAVAEE, 2008). O cliente envia uma requisio HTTP para o servidor WEB. O servidor WEB que implementa o Java Servlet e Java Server Pages (JSP) converte a requisio em um objeto do tipo HTTPServletRequest. Esse objeto encaminhado para um componente WEB, que pode interagir com JavaBeans (seo 6.1.1.1.4) ou com um banco de dados, a fim de gerar contedo dinmico. O componente WEB posteriormente pode gerar um HTTPServletResponse ou repassar a requisio para outro componente. Geralmente, gerado um objeto do tipo HTTPServletResponse. O servidor Web converte esse objeto em uma resposta (response) HTTP e a retorna ao cliente. 116

Figura 6.3 - Exemplo de interao entre um cliente e uma aplicao WEB.

6.1.1.1.1. SERVLET
Os servlets so basicamente classes Java que podem dinamicamente processar requisies e construir respostas HTTP. Dessa forma os servlets propiciam novos recursos ao servidor, sendo em geral definidos como extenses dos servidores. O servlet disponibiliza uma interface para o servidor WEB (ou servidor de aplicao) atravs de uma API. As aplicaes baseadas em servlets geram contedo dinmico (normalmente HTML) e interagem com os clientes utilizado o paradigma request/response. Os servlets geralmente utilizam o protocolo HTTP, mas no so restritos a ele e foram implementados de forma genrica e independente do protocolo de comunicao utilizado. Alm disso, o servlet necessita de um container WEB para ser executado.

6.1.1.1.2. JSP (JAVA SERVER PAGES)

As pginas JSP so documentos baseados em texto que executam como servlet, mas que permitem uma abordagem mais natural para desenvolvimento de contedo esttico de apresentao de uma pgina WEB. As pginas JSP so uma alternativa ao ASP e PHP. Alm disso, as JSPs podem ser utilizadas para acessar bancos de dados, obter informaes de formulrios, manipular arquivos em formato texto e obter informaes sobre o visitante e o servidor. Dessa forma, as JSPs permitem que contedo dinmico seja gerado e apresentado em uma pgina WEB. Nessas situaes, o contedo dinmico geralmente obtido atravs de cdigos Java e apresentado atravs de HTML. Logo, as pginas JSP permitem a utilizao de cdigo Java e HTML no mesmo arquivo.

117

Tanto servlets quanto JSPs podem ser utilizados de forma intercambivel, mas cada um mais adequado para um tipo de funcionalidade. Os servlets so mais adequados para fazer controle da aplicao e processamento dos dados. J as pginas JSP so mais adequadas para gerao de texto de apresentao de dados baseados em HTML, XML, dentre outros.

6.1.1.1.3. JSTL (JSP STANDARD TAG LIBRARY)

Apesar de as pginas JSP serem mais adequadas para gerao de contedo WEB dinmico, elas adicionam o inconveniente de tornar o cdigo pouco legvel devido a utilizao de cdigo Java e HTML de forma entrelaada. Esse inconveniente foi minimizado com o desenvolvimento da JSTL. JSTL consiste de uma biblioteca de tags JSP padronizadas, onde cada uma possui um propsito especfico, permitindo escrever pginas JSP sem cdigo Java, aumentando assim a legibilidade dos cdigos de uma pgina JSP. Ento, basicamente, uma pgina JSTL uma pgina JSP com tags JSTL. Cada tag realiza um tipo de processamento, que similar funcionalidade que seria obtida utilizando cdigo Java.

6.1.1.1.4. JAVABEANS
Os JavaBeans so componentes de software Java. De acordo com a Sun Microsystems (SUN, 2009), os JavaBeans so componentes reutilizveis de software que podem ser manipulados visualmente com a ajuda de uma ferramenta de desenvolvimento. Para ser de fato considerado um JavaBean, uma classe deve seguir algumas convenes de nomenclatura de mtodo, construtores e comportamento. Essas convenes permitem a identificao de um JavaBean por parte das ferramentas e as mesmas podem ento manipul-los de forma adequada. As convenes que uma classe deve seguir so: Implementar a interface java.io.Serializable (que possibilita a persistncia e restaurao do estado do objeto da classe); Possuir um construtor sem argumentos; Permitir que as suas propriedades sejam acessveis atravs de mtodos "get" e "set", seguindo o padro de nomenclatura; Possa conter qualquer mtodo de tratamento de eventos.

118

6.1.2. MVC E ARQUITETURA EM 3 CAMADAS

O conceito da trade de classes Model-View-Controller (MVC) foi utilizado, originalmente, para construir interfaces grficas com o usurio na linguagem de programao Smalltalk-80 (GAMMA; HELM; JOHNSON; VLISSIDES, 1994). A abordagem MVC composta de trs tipos de objetos. O Modelo (Model) o objeto de aplicao, o controlador (Controller) o que define o comportamento da interface, a partir das informaes submetidas pelo usurio e a Viso (View) responsvel pela apresentao das informaes na tela. Antes do MVC, os projetos de interface de usurio tendiam a agrupar esses objetos, gerando um cdigo monoltico. O MVC separa esses objetos a fim de aumentar a reutilizao e flexibilidade. Na Figura 6.4 (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) pode ser vista uma das grandes vantagens da utilizao do MVC (os controladores foram abstrados para simplificar a figura). A partir dos dados disponibilizados por um nico modelo, diferentes formas de apresentaes foram construdas. Isso possvel, porque no h um acoplamento forte entre os dois objetos, ou seja, o objeto de modelo no possui cdigos relacionados lgica de aplicao. Ento, fica como responsabilidade da classe de viso ter acesso aos dados e incluir todo o cdigo para apresent-los da forma desejada. Caso o cdigo fosse monoltico e j existisse uma apresentao em forma de tabelas, por exemplo, mudar para um grfico tipo pizza no seria uma tarefa agradvel, j que haveria cdigos relacionais ao modelo, controle e apresentao em um mesmo bloco e se perderiam, ento, as capacidades de reutilizao e a flexibilidade. A abordagem MVC fica ainda mais evidente, se diferentes tecnologias de viso forem utilizadas. Por exemplo, uma aplicao Desktop necessita ser convertida em uma aplicao WEB: se o modelo MVC foi bem utilizado, duas das trs camadas lgicas (Controle e Modelo) sero preservadas, mudando apenas a tecnologia da viso, que obrigatria neste caso. Novamente, se o cdigo fosse monoltico, todas as camadas teriam sua preservao e reutilizao comprometidas.

Figura 6.4 MVC: flexibilidade na apresentao do mesmo conjunto de dados.

O objetivo da arquitetura em trs camadas a separao das funcionalidades de um software utilizando camadas. Em uma arquitetura de trs camadas se cria uma camada para 119

lgica de apresentao, lgica de negcio e a lgica de acesso aos dados (conexo com banco de dados). Essa separao torna o sistema mais flexvel e reutilizvel, pois as camadas podem ser alteradas de forma independente. Alm disso, se a interface de comunicao entre as mesmas permanecer inalterada, as camadas podem ser alteradas ou at mesmo substitudas, sem influenciar nas demais. Na Figura 6.5 (NETO; NADALETE; GENNARI; FREITAS 2009) pode ser visto o poder de reutilizao e flexibilidade da arquitetura em trs camadas, onde um mesmo sistema utilizado por duas tecnologias de viso e de acesso a dados persistentes diferentes. Ou seja, a camada de lgica de negcio, que a parte principal da aplicao, permanece praticamente intacta e as camadas que so dependentes de tecnologias podem ser substitudas ou alteradas quando for necessrio.

Figura 6.5 - Representao de uma arquitetura em trs camadas utilizando diferentes tecnologias de viso e persistncia.

Certamente, os conceitos MVC e arquitetura em trs camadas so similares, mas no iguais. Na verdade, h uma grande discusso em torno desses conceitos: alguns autores consideram que so equivalentes e outros no. Mas, no interessante entrar no mrito dessa discusso e sim perceber que no seria um erro simplesmente nomear as camadas da arquitetura em trs camadas com a nomenclatura do MVC, a fim de simplificar e tornar mais intuitiva o seu significado. Ento, na arquitetura em trs camadas os nomes seriam: Viso Lgica de apresentao; Controle Lgica de negcio; Modelo Objetos a serem persistidos pela lgica de acesso a dados. Um bom argumento para se dizer que a abordagem MVC e a arquitetura em trs camadas no so idnticas pode ser visto se compararmos as Figura 6.5 e 6.6 (BALAZS, 2009). As camadas intermedirias do MVC (Controle) e da arquitetura em trs camadas (lgica de negcio) possuem papis diferentes. Alm disso, o MVC permite que a Viso (camada mais superior) se comunique diretamente com o Modelo (camada mais inferior), j na arquitetura em trs camadas a camada mais superior (Apresentao) s pode se comunicar atravs da camada intermediria (Lgica de negcio) com a camada mais inferior (Acesso a dados). Certamente isso acontece porque os objetivos dos dois modelos so diferentes: um deles foi idealizado para construo de interfaces grficas e o outro para aplicaes de propsito geral, 120

principalmente baseadas na WEB. O MVC original ainda promove um certo acoplamento entre as camadas superior e inferior, j a arquitetura em trs camadas no, e exatamente por isso que mudanas de tecnologias nessas duas camadas podem ser feitas com poucas ressalvas. Certamente no o que ocorre no MVC e nem esse seu intuito original.

Figura 6.6 - Relacionamento entre as camadas do MVC.

6.1.3. PADRES DE PROJETO

De acordo com (GAMMA; HELM; JOHNSON; VLISSIDES, 1994), Projetar um software orientado a objetos difcil, mas projetar software reutilizvel orientado a objetos mais difcil ainda. muito comum no desenvolvimento de software se ter a sensao de que isso j foi visto antes, ou seja, um mesmo problema em um contexto diferente. Ento, fica a dvida: como seria possvel aplicar uma soluo anterior a esse novo projeto?. Uma das respostas para essa pergunta seria a aplicao de padres de projeto. Os padres de projeto permitem a reutilizao eficaz de solues e arquiteturas bem sucedidas, para construir programas orientandos a objetos, garantindo flexibilidade, facilidade de manuteno e evoluo. A utilizao de padres de projeto pode reduzir o tempo e complexidade do processo de implementao de um software. Alm disso, um software orientado a objetos bem projetado possibilita a reutilizao, ou seja, o emprego de componentes desenvolvidos anteriormente em projetos futuros. Em termos de cdigo, os padres de projeto indicam como as classes devem ser implementadas e como os objetos devem ser utilizados. Para utiliz-los de maneira correta, deve-se conhecer os padres, seu contexto, escopo e aplicao. Ou seja, deve-se analisar o problema e identificar qual padro pode ser aplicado satisfatoriamente para resolver o problema. Inicialmente, esse processo de identificao bem difcil. 121

6.1.3.1. O QUE UM PADRO DE PROJETO?

Os padres de projeto foram propostos inicialmente por Christopher Alexander para problemas de arquitetura na construo civil. Ele afirmava que cada padro descreve um problema no nosso ambiente e o ncleo da sua soluo, de tal forma que voc possa utilizar esta soluo mais de um milho de vezes, sem nunca faz-lo da mesma maneira. Embora este comentrio se refira a padres de arquitetura em construo de casas, prdios, cidades, dentre outros, o seu contexto foi trazido para a computao pelos pesquisadores Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) a famosa gangue dos quatro (GoF Gangue of four). Eles traduziram os padres de arquitetura para o mundo da computao e descobriram contextos onde a mesma soluo poderia ser aplicada vrias vezes. Assim, o conceito de padro de projeto possui quatro elementos essenciais: O nome do padro uma referncia que pode ser utilizada para descrever um problema de projeto, suas solues e conseqncias em uma ou duas palavras; O problema descreve quando aplicar o padro; A soluo descreve os elementos que compem o projeto, suas responsabilidades, relacionamentos e colaboraes; As conseqncias so os resultados, vantagens e desvantagens da aplicao do padro.

Resumindo, um padro se prope a nomear, abstrair e identificar os aspectos mais importantes de um projeto, a fim de tornar esses aspectos um projeto orientado a objetos reutilizvel.

6.1.3.2. OS PADRES DE PROJETO

Nesta seo so apresentados de forma breve os padres de projeto e objetivos originalmente apresentados por (GAMMA; HELM; JOHNSON; VLISSIDES, 1994). So vinte trs padres, divididos nas classificaes: padres de criao, comportamentais e estruturais.

6.1.3.2.1. PADRES DE CRIAO

Os padres de criao basicamente abstraem o processo de instanciao de um objeto. Dessa forma, eles ajudam a tornar um sistema independente de como seus objetos so criados, compostos e representados. Um padro de criao de classe utiliza o mecanismo de herana da orientao a objetos, para variar a classe que instanciada. J o padro de criao de objeto delegar a responsabilidade da instanciao a outro objeto.

122

Padres pertencentes a essa categoria possuem duas caractersticas marcantes: Todos encapsulam conhecimento sobre quais classes concretas so utilizadas pelo sistema; Ocultam o modo como as instncias destas classes so criadas e compostas.

Os padres de criao se tornam importantes medida que os sistemas evoluem e passam a depender mais da composio de objetos do que da herana entre classes. Nessa situao, a definio de um conjunto menor de comportamentos fundamentais passa a ser mais importante que a codificao rgida de um conjunto fixo de comportamentos. A partir de um conjunto menor e mais flexvel de comportamentos pode-se compor comportamentos mais complexos e customizados para o problema em questo. Os padres de projeto de criao propostos pelo GoF (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) podem ser vistos na Tabela 6.1.

Tabela 6.1 - Padres de projeto de criao.

Padro Abstract Factory

Finalidade Fornecer uma interface para se criar conjuntos de objetos que se relacionam ou que so dependentes, sem especificar a classe concreta do mesmo. Facilitar a criao de um objeto complexo, de modo que este processo possa criar diferentes representaes do objeto. Fornecer uma interface para criar um objeto, mas deixar que as subclasses decidam que classe instanciar Especificar os tipos dos objetos a serem criados via uma instncia prottipo, para que depois novos objetos sejam copiados a partir dele. Garantir que um objeto tenha uma nica instncia e fornecer um acesso global mesma.

Builder Factory Method Prototype Singleton

6.1.3.2.2. PADRES ESTRUTURAIS

Os padres estruturais se preocupam com a forma como os objetos e classes so compostos, a fim de formar estruturas maiores. Os padres estruturais de classes utilizam herana para compor interfaces ou implementaes. Por exemplo, a herana mltipla utiliza duas ou mais classes para compor uma terceira maior e mais poderosa, pois esta combina as propriedades das suas classes pai. J os padres estruturais de objetos no se preocupam com a composio de interfaces ou implementaes, mas em descrever maneiras de compor objetos para obter novas funcionalidades. A flexibilidade obtida pela composio de objetos provm da 123

habilidade e capacidade de mudar-se essa composio em tempo de execuo, o que seria impossvel com composies estticas baseadas em classes. Os padres de projeto estruturais propostos pelo GoF (GAMMA; HELM; JOHNSON;
VLISSIDES, 1994) podem ser vistos na Tabela 6.2. Tabela 6.2 - Padres de projeto estruturais.

Padro Adapter Bridge Composite Decorator Facade Flyweight

Finalidade Converte uma interface em outra interface, o que permite que classes com interfaces incompatveis trabalhem em conjunto. Separa uma abstrao de sua implementao, de modo que as duas possam variar (ou trabalhar) independentemente. Compor objetos em estruturas de rvores para representar hierarquias todo-parte. Fornecer de forma dinmica responsabilidades adicionais a objetos. Fornecer uma interface unificada para um conjunto de interfaces em um subsistema. Procura subdividir as informaes comuns a diversos objetos em um nico componente. Os dados particulares e nicos desses objetos passam a ser utilizados como parmetros de mtodos. Prov uma referncia e/ou substituto para controlar o acesso a um objeto, funcionando como um substituto temporrio do mesmo.

Proxy

6.1.3.2.3. PADRES COMPORTAMENTAIS

Os padres comportamentais se preocupam com os algoritmos e a atribuio de responsabilidade entre objetos. Esses padres no descrevem apenas padres de objetos ou classes, mas padronizam tambm a forma como os objetos devem se comunicar. Os padres criam fluxos de controle complexos, que so difceis de serem seguidos em tempo de execuo. Basicamente, eles abstraem o fluxo de controle do programador, para permitir que o mesmo se concentre apenas na maneira como os objetos so interconectados. Os padres comportamentais para classes utilizam a herana para distribuir o comportamento entre as classes. J os padres comportamentais para objetos utilizam a composio de objetos no lugar de herana. Alguns descrevem como um grupo de objetos relacionados cooperam para execuo de uma tarefa, que individualmente no teriam capacidade de realizar. 124

Os padres de projeto comportamentais propostos pelo GoF (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) podem ser vistos na Tabela 6.3.
Tabela 6.3 - Padres de projeto comportamentais.

Padro Chain of Responsability

Finalidade Evita o acoplamento do remetente de uma solicitao ao seu destinatrio, dando a mais de um objeto a chance de tratar a situao. Encapsula uma solicitao como um objeto, de forma que permita a parametrizao com os clientes com diferentes solicitaes, filas ou registro de solicitaes a fim de permitir o cancelamento das mesmas. Dada uma linguagem, define a representao para sua gramtica juntamente com um interpretador que usa a representao para interpretar as sentenas nessa linguagem. Fornece uma maneira de acessar seqencialmente os elementos de um objeto agregado, sem expor sua representao subjacente. Define um objeto que encapsula como um conjunto de objetos interage. Sem violar o encapsulamento, captura e externaliza um estado interno de um objeto, de modo que possa posteriormente ser restaurado para este estado. Define uma dependncia de um para muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes so automaticamente notificados e atualizados. Permite que um objeto altere seu comportamento quando seu estado interno muda. Define uma famlia de algoritmos, encapsulando cada um deles a fim de torn-los intercambiveis. Define o esqueleto de um algoritmo em uma operao, postergando a definio de alguns passos para subclasses. Representa uma operao a ser executada sobre os elementos da estrutura de um objeto, permitindo que seja possvel definir uma nova operao sem mudar as classes dos elementos sobre os quais opera.

Command

Interpreter

Iterator

Mediator Memento

Observer

State Strategy Template Method Visitor

125

6.1.4. PADRES UTILIZADOS

Nessa seo so descritos, de forma um pouco mais detalhada, os padres utilizados no desenvolvimento do sistema WEB. So descritos os padres de projeto clssicos Singleton, Facade e Command, alm do padro para persistncia DAO (Data Access Object) e para arquitetura Layer. Esses dois ltimos no foram originalmente catalogados por (GAMMA; HELM; JOHNSON; VLISSIDES, 1994). Os padres so apresentados de forma breve, baseando-se no problema que o padro busca solucionar, na soluo utilizada pelo padro e nas conseqncias de utilizar o mesmo. Um assunto fundamental, que se refere implementao dos padres, no ser abordada, pois foge um pouco do escopo desse trabalho, mas de fundamental importncia para se poder utilizar os padres. Na seo 6.3.3 so feitos breves comentrios sobre a implementao desses padres no escopo do sistema WEB em desenvolvimento.

6.1.4.1. SINGLETON
O Singleton um padro de criao. O objetivo do mesmo garantir que uma classe tenha uma nica instncia e fornea um ponto de acesso global para a mesma.

6.1.4.1.1. PROBLEMA
Como garantir que uma classe tenha uma nica instncia e que esta seja de fcil acesso?

6.1.4.1.2. SOLUO
Se for buscada uma soluo na programao estruturada, uma varivel global poderia resolver o problema, mas qualquer parte do cdigo poderia alterar essa varivel, mesmo as partes que no deveriam. Isso um grande inconveniente, j que se tem pouco controle do acesso varivel e pode-se promover insegurana no estado da mesma. Uma soluo melhor fazer com que a prpria classe seja responsvel por manter o controle sobre sua nica instncia. A classe ento garante que nenhuma outra instncia dever ser criada (atravs da interceptao das solicitaes para criao de novos objetos), bem como fornecer um meio para acessar essa nica instncia. O padro Singleton adequado quando: For preciso haver uma nica instncia de uma classe, e essa instncia necessitar fornecer acesso atravs de um ponto nico e bem conhecido na aplicao; A instncia nica tiver que ser extensvel atravs de subclasses, possibilitando s classes clientes utilizar uma instncia estendida sem alterar o seu cdigo.

126

6.1.4.1.3. CONSEQUNCIAS
O padro Singleton quando utilizado no escopo de uma aplicao traz as seguintes conseqncias: Acesso controlado nica instncia da classe. Como a classe Singleton encapsula a sua nica instncia, possui total controle sobre como e quando a instncia acessada; Conjunto de entidades (variveis ou objetos) reduzido. O padro Singleton minimiza o uso de variveis globais e evita a utilizao de variveis desse tipo que so declaradas com objetivo de serem nicas, ou seja, possuir uma nica instncia; Permite um nmero varivel de instncias. Se a aplicao necessitar de um nmero customizado de instncias, o padro Singleton garante essa possibilidade e ainda apresenta garantias de controle sobre o nmero de instncias que devero ser criadas.

6.1.4.2. FACADE
Fornece uma interface centralizada de acesso a servios providos por subsistemas, atravs de uma interface de mais alto nvel.

6.1.4.2.1. PROBLEMA
Como fornecer uma interface unificada para um conjunto de interfaces em um subsistema? Como minimizar a comunicao e as dependncias em um subsistema?

6.1.4.2.2. SOLUO
Estruturar um sistema em diversos subsistemas ajuda a diminuir sua complexidade. Alm disso, um objetivo comum em projetos minimizar a comunicao e a dependncia entre os subsistemas. Uma maneira de atingir esse objetivo introduzir um objeto facade, o qual fornece uma interface nica e simplificada para os recursos e facilidades mais gerais de um subsistema. O padro Facade deve ser utilizando quando: Se desejar fornecer uma interface simples para um subsistema complexo; Existirem muitas dependncias entre classes clientes e classes de implementao de um determinado servio ou funcionalidade; Se desejar estruturar um subsistema em camadas.

127

6.1.4.2.3. CONSEQUNCIAS
As conseqncias de utilizar o padro Facade em um projeto so: Isolar os usurios (classes clientes) dos componentes do subsistema, reduzindo dessa forma o nmero de objetos que os clientes devem utilizar e tornando o subsistema mais fcil de usar; Diminui o acoplamento entre o subsistema e seus clientes. Um fraco acoplamento entre os componentes possibilita que alteraes e at mesmo variaes nos componentes sejam feitas sem afetar as classes clientes.

6.1.4.3. COMMAND
Encapsula uma solicitao como um objeto, possibilitando parametrizar clientes com diferentes solicitaes, permitindo tambm enfileirar ou fazer o registro (log) de solicitaes e suportar o processo de desfazer operaes.

6.1.4.3.1. PROBLEMA
Como permitir que objetos especficos faam solicitaes de objetos da aplicao no especificados, transformando a prpria solicitao em um objeto?

6.1.4.3.2. SOLUO
Basicamente, o padro command encapsula as solicitaes como objetos. Dessa forma, possvel parametrizar os clientes atravs dos objetos (servios) solicitados e ainda armazenar ou repassar esses objetos. O padro command adequado quando se deseja: Parametrizar objetos por uma ao a ser executada; Especificar, enfileirar e executar solicitaes em tempos diferentes; Suportar o processo de desfazer operaes; Suportar registro (logging) de mudanas a fim de replic-las, no caso de uma queda do sistema; Estruturar um sistema em torno de operaes de alto nvel construdas sobre operaes primitivas.

128

6.1.4.3.3. CONSEQUNCIAS
As conseqncias de utilizar o padro Command em um projeto so: Desacoplamento entre o objeto que invoca a operao e aquele que sabe como execut-la; Os objetos produzidos pelo padro podem ser manipulados e estendidos como quaisquer outros objetos; possvel unir comandos para formar um comando composto; simples adicionar novos comandos porque no necessrio mudar nenhuma das classes existentes.

6.1.4.4. DAO (DATA ACCESS OBJECT)

O padro DAO fornece um meio prtico de acessar e recuperar informaes de uma base de dados, de forma a separar as outras camadas da aplicao da interao com o banco de dados.

6.1.4.4.1. PROBLEMA
Como abstrair a conexo com o banco de dados e reutilizar comandos SQL?

6.1.4.4.2. SOLUO
muito comum encontrar nas linguagens de programao, APIs para os mais comumente utilizados SGBD existentes. Mas, caso um sistema deseje realizar uma migrao na tecnologia de persistncia, todos os arquivos que manipulam a base de dados devero ser alterados, para utilizar a API da tecnologia de persistncia para a qual o sistema ser migrado. Para resolver o problema de acoplamento entre a tecnologia de persistncia e as classes que manipulam a base de dados, o padro DAO fornece uma interface independente, que deve ser utilizada para persistir objetos de dados. Basicamente, a idia colocar todas as funcionalidades de acesso e conexo base de dados em um s local, tornando simples sua manuteno. Resumindo, a interface DAO especifica como so as assinaturas dos mtodos (parmetros, nome, tipo de retorno, dentre outros) e as classes DAO se responsabilizam por implementar esses mtodos. Dessa forma, no importa se a implementao feita utilizando arquivos ou um SGBD, por exemplo, j que a interface unificada e apenas a implementao muda. Alm disso, a camada imediatamente superior utilizar a interface para acesso aos dados e no a implementao. 129

6.1.4.4.3. CONSEQUNCIAS
As conseqncias de utilizar o padro DAO em um projeto so: Transparncia e independncia na forma de persistncia de dados; Facilidade de migrao de um tipo de fonte de dados para outro (ex: MySQL para PostgreeSQL); Reduo na complexidade da implementao das classes responsveis pela lgica de negcio; Centralizao das classes de acesso s fontes de dados em uma camada;

6.1.4.5. LAYER
Propicia a estruturao de aplicaes que podem ser decompostas em subsistemas, no qual cada um um nvel particular de abstrao.

6.1.4.5.1. PROBLEMA
Como desacoplar e propiciar uma estruturao em sistemas em que as caractersticas dominantes so um conjunto de problemas de diferentes nveis e contextos?

6.1.4.5.2. SOLUO
Deve-se estruturar o sistema em um nmero apropriado de camadas, onde todos os componentes de uma camada esto em um mesmo nvel de abstrao. Alm disso, uma camada deve acessar os servios providos apenas pela camada imediatamente inferior e uma camada deve prover servios para a camada imediatamente superior. Em geral, a decomposio do sistema feita atravs de camadas e parties. Uma camada um subsistema que composto por subsistemas de menor nvel de abstrao, j a partio um subsistema no mesmo nvel de abstrao de outros subsistemas dentro de uma mesma camada. Resumindo, as camadas so compostas por parties e as parties esto relacionadas a uma determinada camada. Uma observao importante que os subsistemas devem ser coesos, logo possuem um forte acoplamento dentro de um subsistema e fraco acoplamento entre subsistemas.

130

6.1.4.5.3. CONSEQUNCIAS
As conseqncias de utilizar o padro arquitetural Layer so: Possvel reutilizao das camadas; Suporte padronizao; As dependncias no esto espalhadas pelo cdigo de implementao; Facilidade de mudana; Menor eficincia;

6.2. METODOLOGIA
Nesta seo so apresentadas as ferramentas e tecnologias utilizadas durante o processo de desenvolvimento do sistema WEB.

6.2.1. NETBEANS IDE

O NetBeans (NETBEANS, 2009) um IDE (Ambiente de Desenvolvimento Integrado) gratuito e de cdigo-livre para desenvolvedores de software na linguagem Java. O NetBeans oferece ao programador um conjunto de ferramentas e funcionalidades para o desenvolvimento de aplicaes profissionais para Desktop, WEB, mveis e coorporativas. O NetBeans foi desenvolvido em Java, logo multiplataforma e funciona em qualquer sistema operacional que tenha suporta mquina virtual Java (JVM). A interface grfica do NetBeans pode ser vista na Figura 6.7. Alguns dos principais recursos do NetBeans so: Editor de cdigo fonte integrado, rico em recursos para aplicaes Web (Servlets e JSP, JSTL, JSF, EJB) e aplicaes visuais com Swing, que uma API (Interface de Programao de Aplicativos) Java para interfaces grficas tpicas de Desktop. Suporte a plataforma JEE (Java Enterprise Edition); Visualizador de classes integrado ao de interfaces, que gera automaticamente o cdigo dos componentes de forma bem organizada e estruturada, facilitando assim a compreenso e legibilidade; Plugins para UML; Suporte a programas de controle de verso como o CVS; Ajuda local e on-line; Depurao completa de aplicaes e componentes; Capacidade de auto-completar; Suporte a banco de dados. Suporte a diversos servidores WEB, container de servlets e servidores de aplicao; 131

Figura 6.7 - Interface grfica do Netbeans.

6.2.2. JSF (JAVA SERVER FACES)

O JSF um framework MVC desenvolvido pela Sun Microsystems e faz parte da plataforma JEE (JAVAEE, 2008). O framework foi projetado para facilitar o desenvolvimento de aplicaes WEB , baseadas em pginas JSP, atravs de componentes grficos de interface do usurio (GUI). Permite tambm conectar esses componentes prprios de forma gil aos objetos de negcio. O surgimento do JSF veio da necessidade de permitir o desenvolvimento de pginas WEB de forma visual, ou seja, no esquema de arrastar e soltar os componentes na tela, que neste caso uma pgina JSP. Apesar de o objetivo do JSF ser de possibilitar a construo pginas JSP a partir de componentes visuais, nada impede que o usurio construa manualmente as pginas, j que o JSF fornece um conjunto de componentes UI (User Interface) e tags que permitem o desenvolvimento das pginas JSF. O que as ferramentas visuais para JSF fazem apenas automatizar o processo e gerar o cdigo equivalente configurao visual da pgina JSP desenhada pelo desenvolvedor. Algumas caractersticas do JSF so:

Permite o desenvolvimento de UIs atravs de um conjunto de componentes UIs pr-definidos; Reutiliza componentes da pgina; Fornece um conjunto de tags JSP para acessar os componentes; Fornece separao lgica de funes que envolvem a construo de aplicaes WEB; Associa os eventos do lado cliente com os manipuladores dos eventos do lado do servidor; Possui um conjunto padro de componentes de interface de usurio que possibilitam validao padronizada; Suporte internacionalizao e acessibilidade; 132

Um modelo de eventos do lado servidor ("server-side event model"); Gerncia de estados;

Na Figura 6.8 (JAVAEE, 2008) pode ser visto o esquema de funcionamento de uma interface de usurio (representada por myUI na Figura 6.8) executando no servidor e sendo enviada ao cliente.

Figura 6.8 - Funcionamento de uma interface de usurio com o JSF.

A pgina JSP, mypage.jsp, uma pgina JSF, ou seja, uma pgina JSP que inclui tags JSF. Ela expressa os componentes de interface do usurio atravs da utilizao de tags JSF. O componente UI da aplicao WEB (representados por myUI) gerencia os objetos referenciados pela pgina JSP. Esses objetos podem ser: Componentes UI que so mapeados para tags na pgina JSP; Quaisquer receptores ouvintes de evento, validadores e conversores que so registrados em um determinado componente; Componentes JavaBeans que encapsulam dados e funcionalidades especficas da aplicao, definidas para um determinado componente.

6.2.3. HIBERNATE
O Hibernate um framework para o mapeamento objeto-relacional desenvolvido em Java. Ele facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicao, atravs do uso de arquivos XML e anotaes. Alm disso, o Hibernate um software de cdigo livre, distribudo sobre a licena LGPL. A principal caracterstica e funcionalidade do Hibernate a transformao das classes Java para tabelas em um banco de dados. O mesmo gera as instrues SQL e deixa o desenvolvedor livre do trabalho manual de converso dos dados, mantendo, dessa forma, o programa portvel para qualquer SGBD baseado em SQL, mas causando uma pequena perda de desempenho observada pela aumento do tempo de execuo. O HQL (Hibernate Query Language) um dialeto SQL para comunicao com o Hibernate. Ela uma poderosa linguagem de consulta, que se parece muito com o SQL. A principal diferena que a HQL totalmente orientada a objeto e inclui os paradigmas de herana, polimorfismo e encapsulamento. No Hibernate, possvel usar tanto SQL quanto HQL. 133

6.2.4. JFREECHART
O JFreeChart hoje provavelmente a biblioteca mais famosa do mundo Java para desenvolvimento de grficos (JFREECHART, 2009). Alm disso, o JFreeChart um projeto de software livre, iniciado em 2000, e com ampla aceitao no mercado. O JFreeChart possui licena LGPL que permite a sua utilizao em projetos de cdigo-fechado. O JFreeChart alm de ser livre, bastante robusto e flexvel. possvel utilizar a biblioteca para o desenho de diversos tipos de grficos: pontos, financeiros, barra, pizza, 2D, 3D, dentre outros. Alm disso, o mesmo gera arquivos no formato JPG, PNG, SVG, EPS e exibe em componentes Swing, que so os componentes grficos tpicos de Desktop do Java. Dois exemplos de grficos produzidos pelo JFreeChart e apresentados em componentes Swing podem ser vistos na Figura 6.9.

Figura 6.9 - Exemplos de grficos produzidos com o JFreeChart.

6.2.5. JASPER REPORTS E IREPORT

O JasperReports (JASPERREPORTS, 2009) uma biblioteca escrita em Java, de cdigo-fonte livre, projetada para facilitar a tarefa de criar relatrios para aplicaes, sejam elas em Desktop ou WEB. O JasperReports fornece uma API para facilitar o desenvolvimento de relatrios, mas ainda sim exige que o desenvolvedor conhea o formato XML utilizado pelo JasperReports para criar relatrios, o que consome muito de tempo de um usurio iniciante. O iReport um programa de cdigo-livre capaz de criar visualmente os mais complexos relatrios possveis para aplicaes Java, no formato da biblioteca JasperReports. Com a popularidade do iReport, a JasperSoft (empresa responsvel pelo JasperReports) tornou esse ferramenta oficial para construo de relatrios para o JasperReports.

134

6.2.6. GLASSFISH
O Glashfish (GLASSFISH, 2009) um servidor de aplicaes desenvolvido pela Sun Microsystems para a plataforma JEE. As principais caractersticas do Glassfish so: Implementa os mais novos recursos disponibilizados pela plataforma JEE 5, que ajudam a aumentar eficincia do desenvolvedor; Aumenta a produtividade do desenvolvedor com APIs JEE simplificadas e recursos de anotaes, que reduzem a quantidade de cdigo da aplicao a ser desenvolvida; Fornece uma arquitetura aberta e extensvel para colaborao entre tecnologia de integrao e servios WEB em uma arquitetura orientada a servios (SOA). Servidor de aplicaes padro utilizada pela ferramenta NetBeans IDE; Possui cdigo-livre;

O logo do projeto Glassfish pode ser visto na Figura 6.10 (GLASSFISH, 2009).

Figura 6.10 - Logo do servidor de aplicaes Glassfish.

6.3. ESPECIFICAO
Nessa seo so apresentados alguns diagramas UML 2.0 que descrevem as caractersticas, requisitos e arquitetura do sistema WEB desenvolvido para o monitoramento de temperatura. Os diagramas UML utilizados so: diagrama de casos de uso e diagramas de classe. A arquitetura do sistema apresentada de forma incremental, atravs de trs diagramas de classe: arquitetura em trs camadas com a notao MVC, arquitetura refinada com padres de projeto e arquitetura com JSF e Hibernate.

135

6.3.1. DIAGRAMA DE CASOS DE USO

Na Figura 6.11 pode ser visto o diagrama de casos de uso do sistema WEB especificado. O diagrama apresenta apenas os casos de uso relacionados ao usurio Administrador, j que o sistema foi idealizado para ser utilizado como um sistema de administrao e monitoramento apenas. Alm disso, esse sistema WEB deve ser capaz de fornecer um meio para que seus prprios servios sejam configurados, bem como o comportamento/funcionamento do JDaemon (Captulo 5). Para ter acesso s funcionalidades do sistema, deve-se primeiro realizar o processo de autenticao no mesmo. O ator Administrador pode, atravs do caso de uso Administrador Sistema WEB, executar os casos de uso cadastrar um novo administrador, alterar administrador, remover administrador ou listar administradores. Alm disso, ele tambm pode, atravs do caso de uso Configurar Servios, executar os casos de uso Configurar Sistema WEB e Configurar Daemon, responsveis respectivamente pela configurao do sistema WEB e do Daemon para aquisio remota de temperatura. Por fim, a principal funcionalidade do sistema utilizada atravs da execuo do caso de uso Verificar relatrios de temperatura, que executa obrigatoriamente os casos de uso Verificar alarmes de temperatura e Verificar grficos de temperatura. Esses dois ltimos casos de uso podem ser executados individualmente, caso o usurio administrador queira apenas obter informaes sobre os alarmes ou verificar a dinmica da temperatura atravs dos grficos. O caso de uso Verificar relatrio de temperatura apresenta um relatrio completo, ou seja, com as informaes de alarme e os grficos.

136

Figura 6.11 - Diagrama de casos de uso do sistema WEB.

6.3.2. DIAGRAMA DE CLASSE: ARQUITETURA EM TRS CAMADAS

Na Figura 6.12 apresentada de forma resumida a arquitetura em trs camadas do sistema. Essa no foi a arquitetura utilizada para implementao, mas serviu como base para definio das camadas e para possibilitar uma maior facilidade na aplicao dos padres de projeto e utilizao das tecnologias (JSF e Hibernate). Essa arquitetura divide o sistema nas camadas: apresentao, negcio e dados. Sendo que a nomenclatura utilizada para defini-las foi a do MVC. Alm disso, pode-se dizer que essa arquitetura utiliza o padro layer, pois a mesma permite comunicao apenas no sentido da camada superior para a imediatamente inferior e organiza o sistema em camadas e parties. As camadas utilizadas (viso, negcio e dados) podem ser observadas na Figura 6.12. J as parties so os componentes de uma determinada camada, a saber: Camada de viso PagCadastroPessoa, PagVerGrafico, PagVerRelatrio, dentre outros; Camada de negcio ControladorPessoa, ControladorRelatorio, ControladorGrafico, dentre outros; Camada de dados Pessoa, Grafico, Relatorio, dentre outros. As classes relacionadas s camadas (Viso, Controle e Modelo) podem ser identificadas, respectivamente, atravs dos esteretipos Boundary, Control e Entity. O esteretipo Persistente foi utilizado para indicar quais classes de modelo devem ser persistidas, ou seja, as que devem ter uma tabela no banco de dados. 137

Essa arquitetura inicial foi muito importante para estruturar o sistema e identificar as camadas e suas parties. Alm disso, atravs da construo da mesma, o processo de aplicar padres de projeto no sistema foi bastante facilitado.

Figura 6.12 - Arquitetura em trs camadas utilizando a nomenclatura MVC.

6.3.3. DIAGRAMA DE CLASSE: ARQUITETURA REFINADA COM PADRES DE PROJETO

Apesar de a arquitetura da seo 6.3.2 j fornecer uma boa estruturao para a implementao, ainda sim possvel aplicar padres de projeto, a fim de introduzir algumas melhorias e aumentar a reutilizao. Na Figura 6.13 pode ser visto a arquitetura em trs camadas refinada com padres de projeto. A camada de GUI (ou viso) composto por um nico servlet, um conjunto de pginas JSP e comandos. Os comandos so classes que utilizam o padro command para encapsular, atravs de um objeto, a requisio do usurio por uma funcionalidade do sistema. Um nico servlet foi utilizado para facilitar a manuteno e aumentar o desempenho da aplicao. O servlet um componente multithread, logo apenas um pode atender s vrias requisies de forma concorrente. Um inconveniente na utilizao do servlet que cada requisio/resposta gerada pelo sistema WEB deve ser tratada pelo servlet. Na prtica, 138

significa que toda vez que o servlet receber uma requisio, ele deve inicialmente identificar, atravs de uma estrutura condicional (IF), o que est sendo solicitado ou submetido e em seguida deve fazer o tratamento adequado. Em geral, cada formulrio de sistema WEB introduziria uma verificao condicional no servlet e seu respectivo cdigo de tratamento. Logo, se o sistema possuir, por exemplo, 400 formulrios, o processo fica bastante invivel e de manuteno difcil. O padro command resolve esse problema, utilizando uma estrutura de dados chamada hashtable, que armazena objetos comando associando-os a chaves. Atravs dessas chaves pode-se recuperar um determinado comando especfico. Alm disso, criada uma classe abstrata chamada ComandoGenerico, com um nico mtodo abstrato, que deve ser implementado por todas as classes que estendem a mesma. Ento, criada para cada possvel requisio um comando que estende a classe ComandoGenerico e implementa o mtodo abstrato com o respectivo tratamento que se deseja para essa requisio. Posteriormente, no servlet so criados todos os objetos comandos utilizados pelo sistema e inseridos na hashtable com uma chave que identifica a funcionalidade desse comando. Assim, quando uma requisio/solicitao recebida pelo servlet, o mesmo procura na hashtable o comando adequado para trat-la e o executa. Dessa forma, no mais necessria nenhuma verificao condicional e implementao do tratamento da requisio dentro do prprio servlet: o padro command se encarrega de identificar a requisio e executar o comando especifico, ou seja, o padro faz basicamente um roteamento entre o servio solicitado e sua implementao. Adicionar novos comandos muito simples, basicamente deve-se implementar o comando desejado e inserir na hashtable, introduzindo apenas uma linha de cdigo no servlet ao invs de dezenas como era esperado anteriormente. Outro problema com a arquitetura da seo 6.3.2 que h um acoplamento muito forte entre as camadas de viso e negcio. Alm disso, cada pgina da viso deve conhecer o controlador associado, tornando o acesso a funcionalidades e servios bastante desestruturado e espalhado. Para resolver esse problema, foi utilizado o padro facade, que introduz uma interface com todos os servios providos pela camada negcio, centralizando e estruturando melhor esse acesso. Logo, as classes de viso apenas precisam conhecer a fachada e no quem so os responsveis pela implementao do servio, ou seja, os controladores. Na implementao da fachada so programados todos os servios providos pela sua interface. Esses servios so basicamente implementados atravs de chamadas (execues) dos controladores para cada servio especfico. Alm de implementar o padro facade, a fachada tambm implementa o padro singleton, que garante que haja apenas uma instncia do objeto fachada no sistema, evitando assim que existam vrias fachadas que provem o mesmo servio. Os controladores possuem o mesmo objetivo que possuam na arquitetura 6.3.2, ou seja, so responsveis pelas lgicas de negcio. Mas h um problema na arquitetura 6.3.2, que o acoplamento da lgica de negcio com a lgica de persistncia. Ou seja, nos controladores ou modelos tambm h cdigos de persistncia. Para resolver esse problema, foi utilizado o padro DAO, o padro cria uma interface que acessada pelos controladores. Dessa forma, o cdigo de persistncia est armazenado na implementao dessa interface DAO e no nos controladores. Logo, se a tecnologia de persistncia for alterada, as classes de negcio permanecero praticamente intactas, pois utilizam a interface e no a implementao, aumentando assim o reuso e manuteno do sistema.

139

Figura 6.13 - Arquitetura em trs camadas refinada com padres de projeto.

140

6.3.4. DIAGRAMA DE CLASSE: ARQUITETURA COM AS TECNOLOGIAS JSF E HIBERNATE

A arquitetura descrita nessa seo utiliza grande parte da arquitetura apresentada anteriormente, mas introduz as tecnologias JSF e Hibernate na mesma. A arquitetura com as tecnologias JSF e Hibernate pode ser vista na Figura 6.14. A vantagem de utilizar o JSF com relao arquitetura do sistema, que o mesmo j implementa o padro command. Dessa forma, as pginas JSP produzidas com JSF j possuem capacidade de rotear a solicitao para o servio especfico, que neste caso provido pela fachada, mas poderia ser provido por um controlador, por exemplo, lembrando que isso induziria a problemas de acoplamento. As vantagens de utilizar o Hibernate se concentram principalmente na implementao. O mesmo capaz de fazer a traduo objeto-relacional automaticamente, o que muito importante se o sistema orientado a objetos e utiliza uma SGBD relacional. Alm disso, o Hibernate possibilita a gerao das tabelas do banco de dados, a partir das classes de entidade (ou modelo) da arquitetura, evitando assim que o desenvolvedor precise gerar as tabelas do banco de dados manualmente. O Hibernate tambm possui drivers para maioria dos SGBD e possibilita que o sistema possa trocar de tecnologia de persistncia, alterando apenas uma linha no arquivo de configurao, que responsvel por indicar qual o SGBD est sendo utilizado. Em geral, quando apenas o padro DAO utilizado, se a tecnologia de persistncia alterada, uma nova implementao dos DAO tambm se faz necessria. J quando o sistema utiliza o Hibernate, os DAOs no precisam ser rescritos, j que a manipulao do banco de dados provida atravs de uma interface comum para os SGBD. A utilizao de frameworks como Hibernate e JSF diminuem o acoplamento entre os subsistemas da aplicao, aumentam o reuso e produtividade, j que muitas classes so abstradas pelos prprios frameworks e no precisam ser implementas pelo usurio.

141

Figura 6.14 - Arquitetura com as tecnologias JSF e Hibernate.

142

7. TESTES E RESULTADOS
Neste captulo so apresentados os resultados de alguns testes realizados, com o objetivo de verificar alguns parmetros de desempenho, relacionados ao circuito microcontrolado para monitoramento de temperatura e disponibilizao dos dados via Internet. Os testes foram realizados utilizando as simulaes dos circuitos e os respectivos programas embarcados descritos no captulo 4. O circuito foi testado, utilizando o software embarcado servidor HTTP e cliente TCP. Todos os testes foram realizados com intuito de identificar o tempo de resposta do circuito ao comando ping. O ping um comando de rede que utiliza o protocolo ICMP para testar a conectividade e o tempo de reposta de um dispositivo em rede. Atravs do mesmo foi testado o tempo de resposta do circuito utilizando os dois programas embarcados. Alm disso, o servidor HTTP foi testado em trs cenrios especficos. Os testes foram muito interessantes, pois ficou muito evidente a influncia de cada programa e cenrio no tempo de resposta do circuito quando conectado em rede. Mas a anlise dos testes no foi simples, pois como o circuito simulado em computador, diversos fatores e variveis aleatrias podem influenciar de forma positiva ou negativa no desempenho do circuito, como: programas em execuo, download e upload em curso, dentre outros. Alm desses fatores, tambm influenciam no resultado da simulao: o hardware do computador no qual o simulador executado e a qualidade do enlace da rede. Mas, esses fatores foram abstrados e as justificativas de desempenho foram baseadas apenas nos fatores relacionadas ao circuito e seus programas embarcados. Para realizao dos testes foi utilizado um computador cujos componentes de hardware de interesse so: processador Athlon XP 2600+ (1.91GHz), 2GB de memria RAM e HD (Hard disk) de 250 GB 7200 RPM. O ambiente de teste montado pode ser visto na Figura 7.1. Os dispositivos no interior do retngulo na Figura 7.1 fazem parte do mesmo dispositivo fsico, que um computador do tipo PC. Quando a simulao do circuito ativada no simulador Proteus VSM, o mesmo cria um dispositivo de rede virtual, que representa o circuito. Dessa forma, o mesmo computador PC passa a responder pelo IP 192.168.0.50 (circuito) e 192.168.0.143 (Computador). Os comandos ping foram enviados do dispositivo com IP 192.168.0.143 para o dispositivo com IP 192.168.0.50. Os testes consistiram basicamente na execuo de trs comandos ping seqenciais, em que cada um deles fazia 10 amostragens de conectividade e tempos de resposta, resultando no melhor caso em um conjunto de 30 amostras. Os pacotes perdidos no foram utilizados para o clculo da mdia do tempo de resposta. O tempo de resposta obtido pelo comando ping foi muito importante para se verificar o desempenho do sistema em termos de software e hardware, j que o sistema utiliza programas embarcados, implementados com a estratgia cooperativa multitarefa, na qual cada tarefa tm influencia muito significativa no desempenho geral do sistema. Por exemplo, se uma tarefa demorar mais que o normal, isso fica muito evidente no tempo de resposta e se caracteriza 143

como um pico ou ausncia de tempo de resposta no grfico. O pico ocorre quando uma tarefa demora muito mais que as demais e a ausncia de tempo de resposta ocorre quando no houve uma resposta antes do time out do comando ping.

Figura 7.1 - Ambiente montado para testes de desempenho.

O cenrio lgico para realizao dos testes pode ser visto na Figura 7.2. Ele consiste no uso do Proteus VSM para simulao do circuito e do terminal de comandos do Microsoft Windows XP para executar o comando ping.

Figura 7.2 - Cenrio lgico para os testes de desempenho.

144

7.1. SERVIDOR HTTP MICROCONTROLADO

O servidor HTTP microcontrolado foi testado em trs cenrios especficos: Enviando a pgina HTML armazenada no mesmo; Utilizando apenas requisies AJAX assncronas, para atualizar o valor de temperatura na pgina HTML. Essa situao ocorre quando todo contedo esttico (layout) foi carregado e apenas o contedo dinmico (valor da temperatura) atualizado; Com servidor HTTP inativo. Essa situao ocorre quando no h nenhum tipo de requisio HTTP sendo respondida pelo servidor e o mesmo passa a responder apenas ao comando ping.

Os resultados dos testes nesses trs cenrios so apresentados nas sees 7.1.1, 7.1.2 e 7.1.3.

7.1.1. SERVIDOR HTTP MICROCONTROLADO ENVIANDO UMA PGINA HTML

O grfico que apresenta o resultado dos testes nesse cenrio pode ser visto na Figura 7.3. A mdia das trs execues dos comandos ping so respectivamente 640, 822 e 833 ms. Conforme o mencionado anteriormente, utilizou-se trs comandos ping, onde cada um realizou dez amostras de conectividade e tempo de resposta. As trs seqencias de comandos ping podem ser identificados da seguinte forma: primeira seqncia comandos de nmero 1 a 10; segunda seqncia comandos de nmero 11 a 20; terceira seqncia comandos de nmero 21 a 30. Percebe-se que a primeira execuo teve um tempo mdio de resposta menor que as outras, provavelmente porque o comando foi executado nos instantes iniciais ou finais do processamento de resposta da requisio pela pgina HTML. Observando a Figura 7.3 percebe-se que pelo menos um dos trs primeiros comandos de cada seqncia ultrapassam a mdia do tempo de resposta e tambm so superiores a 1000 ms. Isso ocorre porque esses comandos so executados durante o inicio do processo de resposta da requisio HTTP pela pgina HTML. Nessa etapa so enviados para o navegador WEB do cliente as figuras, textos e demais componentes HTML. Alm disso, os ltimos comandos de cada seqncia (10, 21 e 30) sempre esto abaixo da mdia do tempo de resposta e tambm so inferiores a 500 ms, j que nessa situao grande parte do contedo da pgina HTML j foi enviado para o navegador WEB do cliente.

145

Figura 7.3 - Desempenho do servidor HTTP microcontrolado servindo uma pgina HTML.

7.1.2. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS A REQUISIES ASSNCRONAS AJAX

O grfico que apresenta o resultado dos testes nesse cenrio pode ser visto na Figura 7.4. A mdia dos testes das trs seqncias de comandos ping foram 418, 456 e 459 ms. Percebe-se que o tempo de resposta nessas condies foi menor do que quando o circuito microcontrolado est enviando a pgina HTML. O que faz bastante sentido, j que as requisies assncronas requisitam apenas um valor inteiro, que representa a temperatura, deixando de lado os itens de layout (textos, imagens, tabelas, dentre outros), que j foram requisitados e enviados para o cliente anteriormente.

Figura 7.4 - Desempenho do servidor HTTP microcontrolado respondendo apenas requisies AJAX

146

Observando a Figura 7.4, percebe-se que, neste cenrio, o tempo de reposta mais determinstico do que no cenrio da seo 7.1.1. Isso ocorre porque apenas um pequeno conjunto de requisies bastante similares gerado. Essas requisies so relativas ao valor de temperatura atual, j as da seo 7.1.1 so relativas a figuras, textos, tabelas, dentre outros, que certamente necessitam de tempos distintos para serem completamente enviados ao cliente. Alm disso, o trigsimo comando ping no teve sua requisio respondida a tempo, o que pode ser verificado pela ausncia do tempo de resposta no grfico.

7.1.3. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS AO PING

O grfico que apresenta os dados desse teste pode ser visto na Figura 7.5. A mdia dos testes das trs seqencias de comandos ping foram 106, 57 e 114 ms. O segundo teve em mdia um tempo de resposta menor provavelmente porque imediatamente antes de cada ping, o fluxo de execuo do programa embarcado estava o mais prximo possvel do momento em que o StackManager estava para ser executado e pronto para verificar se havia alguma requisio que deveria ser respondida. Assim, ele pde perceber a requisio e respond-la imediatamente. Mas no geral, isso raramente acontece. Na maioria das vezes, o microcontrolador recebe os pedidos de ping depois de ter executado o StackManager ou bem antes. O normal haver um equilbrio, ou seja, algumas chamadas ao StackManager so muito antes, outras depois e algumas um pouco antes. Logo, quando se faz a mdia, elas se equilibram como o ocorrido durante o primeiro e terceiro teste. J no segundo, a maioria dos comandos ping foram recebidos pelo microcontrolador, imediatamente antes da execuo do StackManager.

Figura 7.5 - Desempenho do servidor HTTP microcontrolado respondendo apenas ao comando "ping".

147

Percebe-se tambm que o tempo de resposta nesse cenrio foi bem menor do que os obtidos nas duas sees anteriores. Isso faz bastante sentido, j que nesta situao o servidor no estava respondendo uma requisio pela pgina HTML e nem respondendo requisies assncronas AJAX. Logo, apenas o servidor ICMP, que o responsvel por responder ao comando ping estava como servio de rede ativo no momento. Alm disso, pode-se perceber, pelo tempo de resposta do vigsimo primeiro ping, que alguma das tarefas demorou mais que o normal. Essa tarefa poderia ser, por exemplo, o processo de converso A/D.

7.2. CLIENTE TCP MICROCONTROLADO

Os resultados dos testes quando o circuito microcontrolado utilizava o software cliente TCP podem ser vistos na Figura 7.6. A mdia dos trs testes foram respectivamente 14, 11 e 12 ms. Percebe-se que os tempos de execuo foram bastante inferiores aos obtidos nas sees anteriores. Isso ocorreu porque no est sendo utilizado nenhum servio da camada de aplicao da pilha TCP/IP, como por exemplo, o HTTP, que foi utilizado nos testes da seo 7.1. Geralmente, so esses servios que utilizam grande parte do poder de processamento do servidor, que neste apenas um microcontrolador. Como pode ser verificado na Figura 7.6, o software embarcado cliente TCP possui o melhor desempenho do que servidor HTTP em todos os cenrios nos quais ele foi testado. Isso se justifica, porque o cliente TCP um software muito mais simples, se comparado ao servidor HTTP: o cliente apenas se conecta a um servidor TCP remoto e disponibiliza um dado que representa a temperatura obtida pelo microcontrolador.

Figura 7.6 - Desempenho do cliente TCP microcontrolado.

148

Pode-se pensar que o correto seria o cliente TCP possuir um tempo de resposta semelhante ao obtido na seo 7.1.3, pois em ambos os casos no est sendo utilizado um servio da camada de aplicao no momento dos testes. Mas h um detalhe importante, no teste da seo 7.1.3, o servidor HTTP no est ativo, mas est habilitado. J no teste da seo corrente, o servidor HTTP no est habilitado. Ento, o gerenciador do servidor HTTP no utiliza nenhum ciclo de mquina para verificar se h alguma requisio que deve ser respondida. J na situao apresentada na seo 7.1.3, o gerenciador do servidor HTTP est continuamente fazendo essa operao.

149

8. CONCLUSES
A Internet embarcada se revela como uma tendncia mundial e uma tecnologia recente e pouco utilizada atualmente. Nesse sentido, importante que se formem recursos humanos para que essa tecnologia possa ser estudada e dominada. A mesma possibilita que, por exemplo, solues de monitoramento ou acionamento remoto via Internet possam ser implementadas, utilizando apenas uma placa ao invs de um computador, diminuindo assim o custo da implantao do servio. No contexto do PoP-RN, o sistema de monitoramento de temperatura proposto contribuir, em um futuro prximo, para a manuteno da infra-estrutura instalada e possibilitar com que anlise de trfego, desempenho e banda possam ser avaliadas em conjunto com o comportamento da temperatura. A pouco mais de um ano, quando foi iniciado o presente trabalho, no havia no mercado uma plataforma nacional para o desenvolvimento de solues utilizando Internet embarcada. Em pouco mais de um ano, as plataformas apresentadas no captulo 2 foram desenvolvidas e passaram a ser comercializadas. Isso evidencia a importncia da iniciativa do presente trabalho. Como havia apenas a plataforma PICDEM.net 2 da Microchip a venda no mercado nacional, um dos objetivos do projeto foi propor uma plataforma similar, mas de baixo custo e dedicada para monitoramento de temperatura, j que a PICDEM.net 2 uma plataforma de propsito geral que possui conectividade Ethernet, mas agrega vrios recursos que no seriam aproveitados a princpio no sistema proposto, e por isso uma plataforma alternativa foi projetada. Assim como a PICDEM.net 2, as demais plataformas apresentadas no captulo 2 tambm so de propsitos gerais e dispem de alguns componentes e caractersticas que no so de interesse, como: conexo USB, leitor de carto SD, capacidade de processamento de udio, dentre outros. Logo, a plataforma descrita neste trabalho certamente teria um custo inferior por ter sido idealizada apenas para monitoramento de temperatura utilizando Internet embarcada, sendo ento um hardware dedicado, ideal e de baixo custo para possibilitar o monitoramento de temperatura na sala de servidores do PoP-RN. Mas ficou muito claro que no Brasil, principalmente no Nordeste, ainda muito difcil concluir, em curto prazo, o desenvolvimento de um hardware complexo como o proposto neste trabalho, pois no h no mercado local empresas que comercializem todos componentes necessrios. Fez-se necessrio, ento, atravs da Internet e telefone entrar em contato com empresas de outros estados e pases, o que se mostrou uma soluo improdutiva e de longo prazo. Assim, como houve um gasto demasiado de tempo com a atividade anterior e tambm como o hardware proposto j havia sido especificado, tendo inclusive 50% do mesmo sido montado em protoboard e verificado seu funcionamento e corretude, o foco do trabalho passou a ser o conjunto de software e sistemas necessrios: cliente TCP e servidor HTTP microcontrolados, daemon para aquisio remota de temperatura via Internet e sistema WEB para monitoramento de temperatura. Em virtude dos problemas para aquisio dos componentes do hardware proposto, o simulador Proteus VSM que j havia sido utilizado nas fases iniciais de estudo de microcontroladores e nos testes da primeira parte do circuito microcontrolado (monitoramento de temperatura), foi muito importante para o desenvolvimento dos programas embarcados servidor HTTP e cliente TCP, pois atravs do mesmo esses programas, bem como a plataforma 150

proposta, foram testados e validados. Nessa circunstncia, ficou muito evidente a qualidade do simulador, pois o mesmo foi capaz de simular o circuito microcontrolado e conect-lo a uma rede Ethernet, fornecendo um comportamento similar ao esperado por um hardware que utiliza a tecnologia Internet embarcada. Ainda em relao aos dois programas embarcados, a Microchip teve uma iniciativa muito nobre, ao disponibilizar uma pilha TCP/IP e ferramentas relacionadas de forma gratuita para utilizao com microcontroladores e DSPs, o que certamente contribuiu e ainda contribuir para a popularizao da tecnologia Internet embarcada. Alm disso, a Microchip tambm disponibiliza gratuitamente uma biblioteca de funes utilitrias baseadas no compilador C18, para uso com microcontroladores da famlia PIC 18F. Por meio dessas duas iniciativas, software complexos como o servidor HTTP e cliente TCP para microcontroladores puderam ser implementados, estes programas so constitudos de um conjunto de aproximadamente 60 arquivos em linguagem C e permitem que um chip (microcontrolador) se conecte Internet, atuando como um servidor de pginas HTML ou um cliente TCP para estabelecimento de conexo remota via socket. O AJAX, apesar de ser uma tecnologia comumente utilizada apenas para promover melhorias na apresentao e interao de sistemas WEB com os usurios, teve um papel muito importante no presente trabalho, uma vez que possibilitou que a temperatura pudesse ser monitorada em tempo real, quando o software embarcado utilizado era o servidor HTTP. A poltica cooperativa multitarefa se mostrou bastante satisfatria e conveniente para implementao de servios complexos (ex: pilha TCP/IP) em sistemas microcontrolados, evitando inclusive a necessidade se utilizar um RTOS. O padro Berkeley Sockets para comunicao em rede utilizando TCP e UDP um grande exemplo da importncia de padronizao de software, pois atravs dessa API, um microcontrolador pde comunicar-se e enviar dados para um computador do tipo PC, sem haver problemas de codificao e ordenao dos bytes (ex: Big Endian ou LittleEndian), que muito comum quando sistemas utilizam processadores diferentes, como neste caso. Em relao ao daemon para aquisio remota de temperatura, estudos sobre programao concorrente (threads, processos, comunicao interprocessos e excluso mtua) e seus mecanismos de suporte (mutex, monitores, semforos, troca de mensagens) foram muito importantes para implementao do mesmo. A utilizao de um sistema baseado em Unix tambm foi relevante, j que atravs do mesmo foi possvel utilizar recursos nativos Unix (signal e alarm) e POSIX (threads e mutex). A especificao em UML foi importante no s como referncia para implementao, mas tambm como documentao para futuras evolues do daemon implementado. O Eclipse CDT se mostrou uma ferramenta muito produtiva para programao em C/C++, pois utiliza de forma integrada o utilitrio make, que facilita bastante a compilao de um projeto que utiliza muitos arquivos e bibliotecas. Alm disso, o mesmo identifica erros de sintaxe e os apresenta de forma visual (sublinhando a linha), o que facilitou a percepo dos mesmos, poupando tempo. O SGBD MySQL realmente de fcil utilizao e fornece uma API para utilizao com a linguagem de programao C, que se mostrou muito simples e robusta. O MTA Postfix cumpriu muito bem o seu papel no desenvolvimento do daemon, pois sua instalao e utilizao foram bastante simples. Alm disso, o mesmo apresentou um desempenho melhor que o sendmail, que havia sido testado anteriormente. Um ponto importante e de dificuldade em relao ao daemon, foi o encapsulamento de recursos de baixo nvel em C para classes C++, o que gerou muitos problemas e, conseqentemente, utilizou uma razovel quantidade de tempo. Ento, se uma implementao em C utilizando recursos de baixo nvel for necessria, um caminho mais 151

conveniente pareceu ser manter a implementao totalmente estruturada, ao invs de introduzir orientao a objetos. Tambm pareceu bastante conveniente evitar a utilizao de recursos concorrentes da linguagem C em classes C++, pois como mencionado no captulo 5, no se conseguiu abrir um arquivo de forma satisfatria utilizando a biblioteca para manipulao de Stream do C++ no interior de um thread padro POSIX. Uma possibilidade futura e alternativa para o daemon, caso seja difcil adicionar novos recursos ao mesmo, seria reprogram-lo utilizando a linguagem Java, pois o Java disponibiliza APIs j orientadas a objetos, que facilitam a reutilizao e flexibilidade quando aplicadas em um determinado software. Deve-se ressaltar, entretanto, que provavelmente o programa em Java ter um menor desempenho, pois o Java interpretado em tempo de execuo por uma mquina virtual. J um cdigo em C/C+ compilado e executado, utilizando a linguagem de mquina nativa da plataforma em questo. Por isso, a C/C++ foi a linguagem de programao escolhida. Em relao ao sistema WEB, a plataforma JEE se mostrou bastante estvel e produtiva para o desenvolvimento de sistemas WEB, pois os componentes providos pela mesma, como: Servlets, JSP, JSTL e JSF, so de simples utilizao. O servidor de aplicaes Glassfish se mostrou bastante eficiente e confivel para execuo de componentes JEE. Provavelmente, por esse motivo, o mesmo o servidor de aplicaes atualmente recomendado pela Sun. Alm disso, a grande vantagem de utilizar a tecnologia Java, alm da portabilidade, o grande fluxo de novidades e APIs implementadas (ex: Jasper Reports para relatrios; JFreechart para grficos), que cada vez mais facilitam o desenvolvimento de sistemas, sejam eles mveis, desktop ou WEB. A arquitetura MVC e em trs camadas foi bastante importante para uma estruturao inicial da aplicao e separao das classes de acordo com sua funcionalidade no escopo do sistema, alm de facilitar futuras migraes na tecnologia de apresentao e persistncia. Dessa forma, o sistema aqui proposto estar apto a mudar para tecnologias alternativas, se necessrio, preservando grande parte da sua lgica de negcio, que o que na verdade caracteriza o sistema. A aplicao dos padres de projeto contribuiu ainda mais para a estruturao das camadas e para aumentar o reuso e flexibilidade da arquitetura, facilitando com que tecnologias como JSF e Hibernate, pudessem ser adicionadas de forma satisfatria sem comprometer a arquitetura elaborada. Alm disso, ter uma arquitetura alternativa, especificada apenas com padres de projeto, importante para que o sistema no fique 100% depende de tecnologias. A espeficicao UML foi importante para o levantamento de requisitos do sistema e para definio da arquitetura a ser utilizada. Essa especificao pode servir como base para a implementao de novos casos de uso e funcionalidades. Em relao aos testes e resultados, os tempos de respostas obtidos nos testes foram coerentes com o esperado na teoria. O software embarcado cliente TCP, que o mais simples, teve o melhor desempenho. Alm disso, o cenrio de teste mais favorvel (respondendo apenas ao comando ping) no qual o servidor HTTP microcontrolado foi testado teve o melhor desempenho dentre os trs cenrios analisados. Uma dvida que pode ter permanecido at o presente momento, seria porque armazenar a temperatura utilizando uma varivel inteira e no uma ponto-flutuante, como era suposto. Nos breves estudos feitos no decorrer desse trabalho, foi constatado que o uso de ponto-flutuante diminui o desempenho global do sistema, j que como foi visto na arquitetura interna do microcontrolador (Seo 3.1.2), o mesmo no tem unidade especifica para tratamento de nmeros em ponto-flutuante. Alm disso, para apresentao de um dado no display LCD, o mesmo deve ser convertido para o tipo string. A biblioteca C18 no dispe de uma funo 152

para essa converso. Mas a mesma foi implementada e verificou-se que utilizava muitos ciclos de mquina e muita memria de programa, sendo provavelmente por esse motivo que a Microchip no incluiu uma funo similar na biblioteca C18. Levando em considerao a experincia obtida durante o desenvolvimento deste trabalho, percebeu-se que se a inteno real de um projeto a implementao de um servio que necessite de um hardware complexo, como o aqui apresentado, o mais indicado seria adquirir uma plataforma comercial, e a partir dela realizar a implantao do servio desejado. Posteriormente, j com o servio implantado e em funcionamento, poderiam ser realizados estudos, a fim de desenvolver uma plataforma alternativa, dedicada e de baixo custo, que pudesse suprir de maneira mais significativa e vivel as necessidades do servio considerado. Se pudesse ter sido adquirida no incio do projeto uma plataforma com Internet embarcada, possivelmente hoje o servio poderia estar em funcionamento ou em fase de implantao. Entretanto, importante que todos os estudos, software e sistemas desenvolvidos sejam vlidos, pois uma soluo alternativa ao desenvolvimento de um hardware dedicado seria realizar a compra de uma das plataformas nacionais apresentadas no Captulo 2, e utilizar os programas embarcados cliente TCP e servidor HTTP nesta plataforma. Diferente das plataformas, o conjunto de software desenvolvido no presente trabalho dificilmente possui uma verso similar, disponvel para venda no mercado, evidenciando assim sua importncia, j que so programas que foram desenvolvidos para solucionar um problema especfico. Alm disso, a implementao dos programas embarcados nestas plataformas no deve ser muito complexa, pois todas as plataformas apresentadas utilizam a soluo para Internet embarcada da Microchip, assim como a plataforma proposta neste trabalho. Alm disso, uma das grandes dificuldades na utilizao da pilha TCP/IP embarcada consiste na configurao da mesma para executar em uma plataforma especfica. Entretanto, todas as plataformas com Internet embarcada baseadas na pilha TCP/IP da Microchip j possuem pelo menos um exemplo de aplicao para testes de conexo Ethernet/Internet. Logo, estas configuraes podem ser observadas e utilizadas por qualquer software embarcado, que venha a utilizar a pilha TCP/IP nestas plataformas. O trabalho aqui apresentado no deveria servir apenas como documentao de uma proposta de projeto, cujo objetivo era solucionar um problema especfico. Mas deve ser visto tambm como um documento que apresenta uma tecnologia que certamente influenciar na rea de redes de computadores e sistemas embarcados, pois em um futuro prximo, muitos dispositivos se conectaro Internet e certamente eles tero um microcontrolador (ou similar), um controlador de rede (Ethernet, Wi-Fi, Bluetooth, dentre outros) e uma pilha TCP/IP embarcada. Em relao ao estgio no PoP-RN/RNP, me sinto um privilegiado por ter tido a oportunidade de ser bolsista. Aprendi muito durante os mais de dois anos de estudo e carrego conhecimentos nicos, que dificilmente teria tido acesso, se no fosse atravs do PoP-RN e das pessoas altamente competentes, que fazem com que o mesmo seja uma instituio de referncia da RNP. Tenho muito orgulho de um dia ter sido parte dessa equipe. Sou muito grato por todo conhecimento e experincia profissional adquiridos e espero ter conseguido retribuir altura, atravs de minhas atividades como bolsista/estagirio.

153

REFERNCIAS BIBLIOGRFICAS
(ANDERSON,1999) Multitasking http://cse.stanford.edu/class/cs110/handouts/32Multitasking.pdf. - <acessado em 20 de Janeiro de 2009>. (BALAZS,2009) A Practical Use of the MVC Pattern http://www.codeproject.com/KB/architecture/PraticalMvc.aspx - <acessado em 09 de Junho de 2009>. (BARNEY,2009) POSIX Threads Programming - https://computing.llnl.gov/tutorials/pthreads/ - <acessado em 12 de Abril de 2009>. (DEBIAN,2009) Debian GNU/LINUX - http://www.debian.org/- <acessado em 05 de Agosto de 2008>. (DE SOUZA,2003A) - Desbravando o PIC - Ampliado e Atualizado para PIC 16F628A, 1 Edio, Editora rica, 2003. (DE SOUZA,2003B) - Conectando o PIC: Recursos Avanados , 2 Edio, Editora rica, 2003. (ECLIPSE, 2009) Eclipse IDE - http://www.eclipse.org <acessado em 03 de maio de 2009>. (EXSTO,2009A) - Exsto - http://www.exsto.com.br - <acessado em 10 de junho de 2009>. (EXSTO,2009B) DsPIC Sigma 128 http://www.exsto.com.br/atual/index.php?page=shop.product_details&flypage=flypage_new.tpl &product_id=23&category_id=1&option=com_virtuemart&Itemid=54 - <acessado em 10 de junho de 2009>. (GAMMA ;HELM; JOHNSON; VLISSIDES, 1994) Design Patterns: Elements of Reusable Object-Oriented Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides. 1 Edio, Editora Bookman. (GLASSFISH, 2009) Glassfish Open Source Application Server - https://glassfish.dev.java.net/ - <acessado em 03 de Maio de 2009> . (GUEDES, 2008) UML: uma abordagem prtica, G. Guedes, 3 Edio, Editora Novatec. (HEIDRICH,2009) Programao Concorrente: Threads http://www.inf.unisinos.br/~barbosa/grefe/atividades/at3/leonardo_3.pdf - <acessado em 20 de Maio de 2009>. (JASPERREPORTS,2009) Jasper Reports Library - http://jasperforge.org - <acessado em 03 de Maio de 2009> (JAVA, 2009) Developer Resources for Java Technology - http://java.sun.com/ - <acessado em 01 de Maro de 2009>. (JAVAEE,2009A) Java Platform, Enterprise Edition - http://java.sun.com/javaee/- <acessado em 01 de Maro de 2009>. (JAVAEE,2008B) - The Java EE 5, Tutorial For Sun Java System Application Server 9.1 http://java.sun.com/javaee/5/docs/tutorial/doc/JavaEETutorial.pdf - <acessado em 03 de Junho de 2009> .

154

(JHD204,2005) Display LCD JHD204 http://www.egochina.net.cn/eshop/ebay/catalog/JHD204A.pdf - <acessado em 16 de Novembro de 2008>. (JFREECHART, 2009) JFreechart Libray - http://www.jfree.org/jfreechart/ - <acessado em 03 de Maio de 2009> . (JUDE, 2009) JUDE/Professional - Design & Modeling - http://jude.change-vision.com/judeweb/index.html - <acessado em 10 de Maio de 2009>. (LABTOOLS,2008A) LabTools - http://www.labtools.com.br/index - <acessado em 10 de junho de 2009>. (LABTOOLS,2008B) Explorer16BR PIC24FJ128GA010-I/PT http://www.labtools.com.br/index.asp?area=21&subarea=b&idioma=por&script=produtos&prod =1054 - <acessado em 10 de junho de 2009>. (LABCENTER,2008) Proteus VSM - http://www.labcenter.co.uk/products/vsm_overview.cfm - <acessado em 15 de Dezembro de 2008>. (LINUX-TUTORIAL,2009) The Life Cycle of Processes - http://www.linuxtutorial.info/modules.php?name=MContent&pageid=84 - <acessado em 11 de Abril de 2009>. (MATTHEW; STONES,2007) Beginnig Linux Programming, N. Matthew, R. Stones, 4 Edio, Editora Wrox. (MELO; NASCIMENTO,2008) PHP Profissional: aprenda a desenvolver sistemas profissionais orientados a objetos com padres de projeto, A. Melo, M. Nascimento, 1 Edio, Editora Novatec. (MICROCHIP,2007) PICDEM.net2 Development Board http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocNa me=en028217 - <acessado em 10 de junho de 2009>. (MICROCHIP,2008A) - Microchip Technology Inc. The Embedded Control Solutions Company - http://www.microchip.com <acessado em 07 de maio de 2009>. (MICROCHIP,2008B) Microchip ENC28J60 http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf Novembro de 2008>. Data <acessado Sheet em 16 de de

(MICROCHIP,2008C) Microchip PIC18F2525/2620/4525/4620 Data Sheet http://ww1.microchip.com/downloads/en/DeviceDoc/39626e.pdf - <acessado em 15 Novembro de 2008>.

(MICROCHIP,2008D) Microchip: TCP/IP download and support http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2505&param= en535724 - <acessado em 25 de Maio de 2008>. (MICROCHIP,2008E) Microchip TCP/IP Stack Application Note http://ww1.microchip.com/downloads/en/AppNotes/00833c.pdf - <acessado em 25 de Maio de 2008>. (MICROCHIP,2008F) MPLAB Integrated Development Environment http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_User_Guide_51519c.pdf <acessado em 20 de Novembro de 2008>. (MICROCHIP,2008G) MPLAB C Compiler for PIC18 MCUs http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_C18_Libraries_51297f.pdf <acessado em 30 de Novembro de 2008>. -

155

(MICROGENIUS,2008A) - Microgenius - http://www.microgenius.com.br- <acessado em 10 de junho de 2009>. (MICROGENIUS,2008B) MagicPIC board http://www.microgenius.com.br/shop/detalhes.asp?id=28&produto=557 - <acessado em 10 de junho de 2009>. (MYSQL,2009) - Manual de Referncia do MYSQL verso 4.1 http://dev.mysql.com/doc/refman/4.1/pt/index.html <acessado em 13 de Maio de 2009>. -

(NATIONAL SEMICONDUCTOR, 1994) - LM35/LM35A/LM35C/LM35CA/LM35D: Precision Centigrade Temperature Sensors http://www.datasheetcatalog.org/datasheet/nationalsemiconductor/DS005516.PDF - <acessado em 16 de Novembro de 2008>. (NETBEANS,2009) - http://www.netbeans.org - <acessado em 01 de Junho de 2009>. (NIEDERAUER,2007) Web Interativa com Ajax e PHP, J. Niederauer, 1 Edio, Editora Novatec. (NETO; NADALETE; GENNARI; FREITAS,2009) Desenvolvimento de Sistema Web utilizando arquitetura em Trs Camadas e Applets http://inf.unisul.br/~ines/workcomp/cd/pdfs/2905.pdf - <acessado em 20 de Junho de 2009>. (PEREIRA,2003) - Microcontroladores PIC Programao em C, 4 Edio, Editora rica. (POSTFIX,2009) MTA Postfix - http://www.postfix.org - <acessado em 20 de Abril de 2009>. (SAMSUNG,2000) Controlador LCD S6A0069 - http://www.egochina.net.cn/eshop/eBay/Datasheet/s6a0069.pdf - <acessado em 16 de Novembro de 2008>. (SANTOS; FIALHO,2008A) SAGA: Um Sistema WEB para Administrao e Gerenciamento de servidores VoIP baseados no Asterisk PBX Relatrio tcnico PoP-RN Johnny C. Maral dos Santos; Sergio V. Fialho. (SANTOS; FIALHO,2008B) WEBSec: Um mdulo de segurana para preveno, deteco e auditoria de ataques WEB Relatrio tcnico PoP-RN Johnny C. Maral dos Santos; Sergio V. Fialho. (SEIXAS FILHO; SZUSTER, 2002) Programao Concorrente em Ambiente Windows: uma viso de automao Constantino Seixas Filho; Marcelo Szuster, 1 Edio, Editora UFMG. (SMITH,2005) Microchip's ENC28J60, World's Smallest Ethernet Controller Seminrio WEB Nate Smith http://techtrain.microchip.com/webseminars/ArchivedDetail.aspx?Active=94 - <acessado em 07 de maio de 2008>. (SILBERSCHATZ; GALVIN; GAGNE,2007) Sistemas Operacionais com Java, A. Silberschatz; P. Galvin; G. Gagne, 7 Edio, Editora Elsevier. (SUN,2009) Sun Microsystems - http://www.sun.com/- <acessado em 01 de Maro de 2009>. (TANENBAUM,2007) Sistemas Operacionais Modernos, A. Tanenbaum, 7 Edio, Editora Prentice Hall. (UML, 2009) Unified Modeling Language - http://www.uml.org//- <acessado em 10 de Maio de 2009>.

156

(WOOD, 2007A) TCP/IP Networking Part 1: Web-Based Status Monitoring Seminrio WEB Elliott Wood http://techtrain.microchip.com/webseminars/ArchivedDetail.aspx?Active=138 - <acessado em 07 de maio de 2008>. (WOOD,2007B) TCP/IP Networking Part 2: Web-Based Control Seminrio WEB Elliott Wood http://techtrain.microchip.com/webseminars/ArchivedDetail.aspx?Active=140 <acessado em 07 de maio de 2008>. (WOOD,2007C) TCP/IP Networking Part 3: Advanced Web-Based Control Seminrio WEB Elliott Wood - http://techtrain.microchip.com/webseminars/ArchivedDetail.aspx?Active=141 <acessado em 07 de maio de 2008>. (YOLINUX,2009) POSIX thread (pthread) libraries - http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html - <acessado em 12 de Abril de 2009>.

157