Projeto PIC Ethernet

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO

Projeto de um sistema microcontrolado utilizando Internet embarcada para monitoramento remoto em tempo real de temperatura e disponibilização dos dados na WEB através de conexão de rede

JOHNNY CEZAR MARÇAL 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 COMPUTAÇÃO E AUTOMAÇÃO

Projeto de um sistema microcontrolado utilizando Internet embarcada para monitoramento remoto em tempo real de temperatura e disponibilização dos dados na WEB através de conexão de rede

JOHNNY CEZAR MARÇAL DOS SANTOS Orientador: Prof. D.Sc. Sergio Vianna Fialho

Trabalho de Conclusão de Curso apresentado ao Programa de Graduação em Engenharia de Computação da Universidade Federal do Rio Grande do Norte como parte dos requisitos para a obtenção do Título de Engenheiro de Computação.

Natal-RN, Julho de 2009 ii

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO

Projeto de um sistema microcontrolado utilizando Internet embarcada para monitoramento remoto em tempo real de temperatura e disponibilização dos dados na WEB através de conexão de rede

JOHNNY CEZAR MARÇAL DOS SANTOS Orientador: Prof. D.Sc. Sergio Vianna Fialho

Trabalho de Conclusão de Curso apresentado ao Programa de Graduação em Engenharia de Computação da Universidade Federal do Rio Grande do Norte como parte dos requisitos para a obtenção do Título de Engenheiro de Computação.

Natal-RN, Julho de 2009 ii

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA DE COMPUTAÇÃO E AUTOMAÇÃO

Trabalho de Conclusão 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. Gláucio Bezerra Brandão DCA / UFRN

Natal-RN, Julho de 2009 iii

AGRADECIMENTOS Agradeço primeiramente a Deus por ter me guiado e iluminado para que eu fizesse as escolhas corretas, que geralmente não são as mais fáceis. À minha mãe, Walmira Judith Marçal dos Santos, pelo total e incondicional amor e carinho, que me fazem ter ânimo e forças para superar qualquer obstáculo, pela privilegiada condição de ser tão amado e querido. Ao meu pai, João Batista dos Santos, pela total confiança e apoio nos momentos mais difíceis da minha vida, pelo exemplo de homem com caráter e integro que é e pelo enorme orgulho que sinto por ser seu filho. Pai e Mãe devo a vocês todas as minhas virtudes e qualidades, devo a vocês tudo de bom que sou e que ainda sonho em ser. Pai e mãe sem vocês seria impossível! Aos grandes amigos e colegas de curso, que certamente contribuíram muito para minha formação como pessoa e como aluno de graduação. Em especial à Anna Giselle Câmara Dantas Ribeiro, Daniel Lopes Martins, Ellon Paiva Mendes, Mário Andrade Viera de Melo Neto e Vinicius Samuel Valério de Souza, que me acompanharam durante quatro anos e meio e fizeram essa trajetória ser divertida, prazerosa e inesquecível. Eu devo muito a vocês! Agradeço também a Tiago Monteiro da Silva por gentilmente ter me cedido o modelo de TCC e ter me auxiliado na utilização do mesmo. Aos demais colegas e amigos não citados, vocês com certeza não foram esquecidos, acreditem! Ao meu orientador Prof. D.Sc Sergio Vianna Fialho, pela grande paciência dedicada a mim durante mais de dois anos em que fui seu aluno de iniciação científica. Não apenas por isso, mas pelo exemplo de caráter, ética, inteligência, humildade, grande conhecimento e competência, que presenciei durante mais de dois anos de convivência. Há dois anos eu fiz uma escolha por um orientador, certamente poderia ter escolhido outros e provavelmente também seria um bom aluno de iniciação científica, mas não tão bom quanto sou hoje: eu fiz a melhor escolha. Ao curso de Engenharia de Computação da UFRN pela ótima formação acadêmica. Aos professores excelentes e brilhantes do Departamento de Engenharia de Computação e Automação (DCA). A alguns igualmente excelentes e brilhantes do Departamento de Matemática e Informática Aplicada (DIMAP). Aos colegas, amigos e funcionários do PoP-RN/RNP. À minha portuguesa favorita, Angela Vitória Guerreiro da Silva, por todo carinho, companheirismo, diversão, 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 distância. Às minhas amigas Thays Magnólia e Priscila Fortunato, por terem recentemente vindo de tão longe me proporcionar alegria, tranqüilidade, afagos, mimos, carinho... Foi muito bom estar com vocês, eu precisava disso (e já estou sentido falta... Voltem, vai...)! Obrigado. Por fim agradeço 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

EPÍGRAFE

“Se você pensa que pode ou sonha que pode, comece. Ousadia tem genialidade, poder e mágica. Ouse fazer e o poder lhe será dado.” — Johann Wolfgang Von Goethe

v

RESUMO O presente Trabalho de Conclusão de Curso apresenta os estudos iniciais relacionados ao projeto de um circuito microcontrolado para monitoramento de temperatura utilizando a tecnologia Internet embarcada. Apresenta também, o projeto de um “software” para aquisição remota de dados e um sistema WEB para monitoramento de temperatura. O sistema aqui proposto, em um futuro próximo, 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 informações sobre a temperatura do ambiente monitorado a qualquer momento, necessitando apenas de conexão 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

SUMÁRIO EPÍGRAFE .............................................. .................................................. ....................................... v RESUMO ............................................... .................................................. .......................................vi ABSTRACT.....................................................................................................................................vii SUMÁRIO.....................................................................................................................................viii LISTA DE FIGURAS.........................................................................................................................xii LISTA DE TABELAS.......................................................................................................................xvii 1. INTRODUÇÃO ........................................... .................................................. ............................... 1 1.1 CONTEXTUALIZAÇÃO.................................. .................................................. ....................... 1 1.2. JUSTIFICATIVA ........................................... ....................................................... .................. 2 1.3. OBJETIVOS ......................................... .................................................. ............................... 2 1.4. METODOLOGIA....................................................... .................................................. .......... 3 1.5. ESTRUTURA ....................................... .................................................. ............................... 4 2. INTERNET EMBARCADA............................................................ ................................................. 5 2.1. INTRODUÇÃO ............................................ .................................................. ....................... 5 2.2. APLICAÇÕES............................... ..................................................... .................................... 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. CARACTERÍSTICAS............................................ .................................................. ........ 12 3.1.2. ARQUITETURA INTERNA......................... ................................................... ................ 14 3.1.3. PINAGEM............................................ .................................................. ..................... 17 viii

3.1.4. CARACTERÍSTICAS ELÉTRICAS....................................................... ............................. 18 3.1.5. CICLOS DE MÁQUINA .............................................. .................................................. 19 3.1.6. ORGANIZAÇÃO DA MEMÓRIA DE PROGRAMA ......................................................... 19 3.1.7. ORGANIZAÇÃO DA MEMÓRIA DADOS ................................................. ..................... 20 3.1.8. CONFIGURAÇÕES DO OSCILADOR..................................................................... ........ 22 3.1.9. PERIFÉRICOS....................................... .................................................. ..................... 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 DISPONIBILIZAÇÃO DOS DADOS ATRAVÉS DE CONEXÃO 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 ATRAVÉS DE UM SERVIDOR HTTP MICROCONTROLADO ........................................................... ........ 69

ix

4.4.5. “SOFTWARE” EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVÉS DE UM CLIENTE TCP MICROCONTROLADO.................. .................................................... ... 88 4.4.6. “SOFTWARE” EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVÉS DE CLIENTE TCP E SERVIDOR HTTP MICROCONTROLADOS ................................................ 91 5. “DAEMON” PARA MONITORAMENTO REMOTO DE TEMPERATURA...................................... 93 5.1. CONSIDERAÇÕES TEÓRICAS ........................................................ ..................................... 93 5.1.1. DAEMON ............................................ .................................................. ..................... 93 5.1.2. UM POUCO SOBRE PROGRAMAÇÃO CONCORRENTE............................................... 94 5.1.3. PROCESSOS......................................... .................................................. ..................... 94 5.1.4.”THREADS” ....................................................... .................................................. ........ 96 5.1.5. PROCESSOS X “THREADS” .................................................... ..................................... 98 5.1.6. COMUNICAÇÃO 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. ESPECIFICAÇÃO ......................................... .................................................. ................... 105 5.3.1. DIAGRAMA DE CASOS DE USO ..................................................... ........................... 105 5.3.2. DIAGRAMA DE CLASSES........................................... ................................................ 106 5.3.3. DIAGRAMA DE TRANSIÇÃO DE ESTADOS .......................................................... ...... 108 5.3.4. DIAGRAMA DE ATIVIDADES..................................... ................................................ 109 5.4. IMPLEMENTAÇÃO .................................................. .................................................. ...... 112 6. SISTEMA WEB PARA MONITORAMENTO DE TEMPERATURA ............................................... 114 6.1. CONSIDERAÇÕES TEÓRICAS ........................................................ ................................... 114 6.1.1. JAVA........................................ ................................................... .............................. 114 x

6.1.2. MVC E ARQUITETURA EM 3 CAMADAS........................... ........................................ 119 6.1.3. PADRÕES DE PROJETO ............................................ ................................................ 121 6.1.4. PADRÕES 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. ESPECIFICAÇÃO ......................................... .................................................. ................... 135 6.3.1. DIAGRAMA DE CASOS DE USO ..................................................... ........................... 136 6.3.2. DIAGRAMA DE CLASSE: ARQUITETURA EM TRÊS CAMADAS .................................. 137 6.3.3. DIAGRAMA DE CLASSE: ARQUITETURA REFINADA COM PADRÕES 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 PÁGINA HTML................ 145 7.1.2. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS A REQUISIÇÕES ASSÍNCRONAS AJAX........................................................................ ................................... 146 7.1.3. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS AO “PING” ......... 147 7.2. CLIENTE TCP MICROCONTROLADO..................................................... ........................... 148 8. CONCLUSÕES............................ ..................................................... ........................................ 150 REFERÊNCIAS BIBLIOGRÁFICAS ................................................. ................................................ 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 memória de programa e pilha dos microcontroladores PIC18F2620/PIC18F4620...................................... .................................................. ..................... 20 Figura 3.5 - Memória de dados dos microcontroladores PIC18F2620/PIC18F4620................... 21 Figura 3.6 - Registradores de Função Especial (SFR) dos microcontroladores PIC18F2620/PIC18F4620...................................... .................................................. ..................... 22 Figura 3.7 - Conexão entre o cristal e o microcontrolador na configuração "Oscilador a Cristal". ................................................... ................................................... ............................................... 23 Figura 3.8 - Modelo genérico 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 módulo conversor A/D.............................................. ....... 27 Figura 3.12 - Diagrama de blocos do MSSP no modo SPI. ................................................. ......... 28 Figura 3.13 - Exemplo de comunicação entre microcontroladores utilizando interface SPI. ..... 29 Figura 3.14 - Encapsulamento do LM35 utilizado........................................................ ............... 30 Figura 3.15 - Configuração 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 - Típico circuito de aplicação do ENC28J60................................................. ............. 34 Figura 3.19 - Componentes padronizados necessários para estabelecer uma interface Ethernet. ................................................... ................................................... ............................................... 34 Figura 3.20 - Esquema de comunicação entre microcontrolador e ENC28J60 utilizando transdutor de nível 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 através do Proteus VSM. ................ 41 Figura 4.4 - Esboço da arquitetura do "hardware" proposto. ............................................ ........ 42 Figura 4.5 - Simulação do circuito microcontrolado para monitoramento de temperatura...... 43 Figura 4.6 - Circuito para monitoramento de temperatura montado em "protoboard". .......... 44 Figura 4.7 - Simulação do circuito microcontrolado para monitoramento de temperatura e disponibilização dos dados via Internet. ................................................ ..................................... 45 Figura 4.8 - Página para monitoramento de temperatura gerada por um servidor HTTP microcontrolado................................... .................................................... ................................... 46 Figura 4.9 - Comunicação entre um cliente TCP microcontrolado e um servidor TCP remoto baseado em um PC............................... ..................................................... .................................. 47 Figura 4.10 - Configurações possíveis 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 necessários para a inicialização do display LCD........................... . 61 Figura 4.13 - Endereçamento direto de um display LCD 16x2............................................... ..... 62 Figura 4.14 - Relação entre posição e valor hexadecimal que deve ser enviado ao display LCD 16x2 para posicionamento manual de cursor............................................................. ................ 62 Figura 4.15 - Relação entre posição 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 - Organização da pilha TCP/IP da Microchip. ................................................ ........... 70 Figura 4.19 - Comparação entre a estrutura da pilha TCP/IP da Microchip e o modelo de referência 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 utilitário MPFS.exe ..................................... 73 Figura 4.24 – Tarefas necessárias para o monitoramento de temperatura. .............................. 82 Figura 4.25 - Modelo clássico de visualização de conteúdos na WEB. ....................................... 82 Figura 4.26 - Modelo AJAX para visualização de conteúdo na WEB. .......................................... 83 Figura 4.27 - Fluxo de dados ao longo do tempo em uma aplicação WEB clássica. ................... 84 Figura 4.28 - Fluxo de dados ao longo do tempo em uma aplicação WEB com AJAX. ............... 84 Figura 4.29 - Gráfico comparativo dos dados transferidos ao longo do tempo entre uma aplicação WEB clássica e outra com AJAX......................................................... .......................... 84 Figura 4.30 - Fluxograma do "software" embarcado para monitoramento de temperatura e disponibilização dos dados utilizando um servidor HTTP microcontrolado. .............................. 87 Figura 4.31 – Diagrama UML de transição de estados do cliente TCP microcontrolado............ 89 Figura 4.32 - Fluxograma do "software" embarcado para monitoramento de temperatura e disponibilização dos dados através de um cliente TCP microcontrolado................... ................ 90 Figura 4.33 - Fluxograma do "software" embarcado para monitoramento de temperatura através de um servidor HTTP e cliente TCP microcontrolados. ............................................. ..... 92 Figura 5.1 - Processos em um ambiente multiprogramado........................... ............................. 95 Figura 5.2 - Possíveis estados de um processo no Linux............................................................. 95 Figura 5.3 - Duas formas de se criar três fluxos de execução usando processos e “threads”. ... 96 Figura 5.4 - Possíveis estados de um "thread" no Linux. ............................................... ............. 97 Figura 5.5 - Comparação em termos de tempo para criação 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 transição 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 aplicações JEE multicamadas. ................................................ ... 116 Figura 6.3 - Exemplo de interação entre um cliente e uma aplicação WEB. ............................ 117 Figura 6.4 – MVC: flexibilidade na apresentação do mesmo conjunto de dados..................... 119 Figura 6.5 - Representação de uma arquitetura em três camadas utilizando diferentes tecnologias de visão e persistência........................................................... ................................ 120 Figura 6.6 - Relacionamento entre as camadas do MVC. .................................................. ....... 121 Figura 6.7 - Interface gráfica do Netbeans........................ .................................................. ...... 132 Figura 6.8 - Funcionamento de uma interface de usuário com o JSF. ...................................... 133 Figura 6.9 - Exemplos de gráficos produzidos com o JFreeChart.............................................. 134 Figura 6.10 - Logo do servidor de aplicações Glassfish.................................................. ........... 135 Figura 6.11 - Diagrama de casos de uso do sistema WEB.............................. ........................... 137 Figura 6.12 - Arquitetura em três camadas utilizando a nomenclatura MVC. ......................... 138 Figura 6.13 - Arquitetura em três camadas refinada com padrões 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 - Cenário lógico para os testes de desempenho. .................................................. ... 144 Figura 7.3 - Desempenho do servidor HTTP microcontrolado servindo uma página HTML..... 146 xv

Figura 7.4 - Desempenho do servidor HTTP microcontrolado respondendo apenas requisições 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 memória dos microcontroladores PIC18F2620 e PIC18F4620. ...... 13 Tabela 3.2 - Periféricos dos microcontroladores PIC18F2620 e PIC18F4620. ............................ 13 Tabela 3.3 - Características elétricas dos microcontroladores PIC18F2620 e PIC18F4620. ....... 18 Tabela 3.4 - Relação entre o modo de oscilação, a freqüência do cristal e os capacitores necessários. ....................................................... .................................................. ........................ 23 Tabela 3.5 - Pinagem do Display LCD JHD204............................................................ ................. 32 Tabela 4.1 - Parcela de tensão que cada "bit" representa em um conversor A/D de 4 “bits” com referência em 5 Volts. .......................................................... .................................................. ..... 49 Tabela 4.2 – Máxima freqüência possível para permitir a operação correta do conversor A/D.53 Tabela 4.3 - Descrição das principais funções do compilador C18 relacionadas ao conversor A/D. ................................................ .................................................. ........................................... 54 Tabela 4.4 - Descrição das principais funções do compilador C18 relacionadas à comunicação com display LCD. ....................................................... .................................................. ................ 63 Tabela 4.5 - Tempo de CPU hipotético para atividades necessárias para realizar o monitoramento de temperatura. .......................................................... ..................................... 81 Tabela 6.1 - Padrões de projeto de criação......................................................................... ...... 123 Tabela 6.2 - Padrões de projeto estruturais........................................................................ ...... 124 Tabela 6.3 - Padrões de projeto comportamentais. ...................................................... ........... 125

xvii

1. INTRODUÇÃO O presente trabalho diz respeito a uma atividade de estágio supervisionado. Este estágio possuiu uma carga horária muito superior à necessária para a conclusão da atividade acadêmica de estágio 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: Multimídia e Internet embarcada. No grupo Multimídia desenvolvi o SAGA (SANTOS; FIALHO, 2008A), que é um Sistema WEB para administração e gerenciamento remoto e em tempo real de servidores VoIP baseados no Asterisk PBX. Esse sistema é atualmente responsável pela administração do serviço VoIP no PoP-RN. Também desenvolvi o WEBSec (SANTOS; FIALHO, 2008B), que é um módulo de segurança para prevenção, detecção e auditoria de ataques WEB, utilizado no SAGA para garantir integridade e confiabilidade na administração do serviço VoIP. No grupo Internet embarcada desenvolvi os estudos e componentes que são apresentados no presente trabalho.

1.1 CONTEXTUALIZAÇÃO O monitoramento a distância de ambientes vem sendo uma atividade de relevante importância, tão logo os avanços tecnológicos o permitiram. Monitorar um ambiente que possua, por exemplo, aparelhos eletroeletrônicos caros, é uma forma adicional de aumentar a garantia de operacionalidade e disponibilidade dos serviços providos por esse ambiente. A área de controle de processos já se encontra bem consolidada e conta com uma quantidade significativa de técnicas e procedimentos variados para a consecução de seus objetivos. Assim, não é nenhuma novidade a implantação de um sistema automatizado para monitoramento de temperatura em determinados ambientes. Entretanto, a digitalização 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 disponibilização desses dados para acesso remoto através das redes de computadores. Essa integração entre os mecanismos tradicionais de monitoramento e a disseminação dos dados obtidos nesse processo através da Internet se constitui no foco do presente projeto. A principal tecnologia utilizada no âmbito deste trabalho é a Internet embarcada, que consiste basicamente na conexão de sistemas embarcados à Internet. Através do uso desta tecnologia, pretende-se possibilitar a integração entre os mecanismos tradicionais de monitoramento e a disseminação dos dados através da Internet. Essencialmente, este trabalho apresenta o projeto de um circuito microcontrolado utilizando Internet embarcada, para monitoramento de temperatura e disponibilização desses dados através da rede de computadores. Além disso, apresenta a implementação dos programas embarcados, para disponibilizar os dados na Internet através de servidor HTTP e cliente TCP microcontrolados. Também fazem parte do escopo desse trabalho, a especificação formal e a 1

implementação inicial de um “daemon” para aquisição remota de temperatura via Internet e de um sistema de informação baseado na WEB para monitoramento de temperatura.

1.2. JUSTIFICATIVA A Internet embarcada se revela como uma tendência 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 obtém dados físicos de um determinado ambiente e utilizam a Internet para transmiti-los, é apenas uma pequena amostra do que essa tecnologia tão promissora vem a acrescentar na área de redes de computadores e sistemas embarcados. Hoje, já é possível, por exemplo, se criar programas cliente/servidor que, utilizando a rede de computadores, verificam “status”, acionam e desligam dispositivos remotamente através de uma simples interface de rede. Investir no estudo dessa tecnologia é um grande passo para que, em um futuro próximo, se possa implementar sistemas com características inovadoras e totalmente integrados à Internet. No contexto do PoP-RN, o sistema de monitoramento de temperatura proposto, além de contribuir para a manutenção da infra-estrutura instalada, possibilitará que uma análise de tráfego, desempenho e banda possa ser avaliada, em conjunto com o comportamento da temperatura. Por exemplo, pode se verificar se nos horários de pico de tráfego 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 rápido possível, o administrador do sistema, sobre algum comportamento inadequado do sistema de refrigeração. Essa não é uma situação tão incomum, uma vez que as freqüentes quedas do fornecimento de energia elétrica ocorridas na UFRN, muitas vezes provocam o desarme dos disjuntores dos circuitos que acionam os equipamentos de refrigeração do PoP-RN. Quando essa situação ocorre durante a noite ou em um fim-de-semana, as conseqüências podem ser danosas à operação desse setor.

1.3. OBJETIVOS O PoP-RN possui uma sala com equipamentos complexos e de alto custo que são utilizados para interconexão de redes de computadores. Esses equipamentos são responsáveis pela comunicação, via Internet, de várias das instituições de ensino superior e pesquisa do RN. Para o seu funcionamento adequado, esses aparelhos necessitam de um ambiente com boa refrigeração e, conseqüentemente, rigoroso controle de temperatura e para isso o sistema proposto foi idealizado. Assim, esse projeto tem como objetivo principal possibilitar, em um futuro próximo, o monitoramento do comportamento da temperatura na sala de servidores do PoP-RN e possibilitar a disseminação desses dados pela rede, a fim possibilitar a visualização remota e em tempo real dos mesmos.

2

Também são objetivos do presente trabalhos os itens a seguir: • • • •

• •

Obter conhecimento teórico e prático sobre a tecnologia Internet embarcada; Adquirir conhecimentos sobre sistemas embarcados e microcontroladores, e sua respectiva conexão 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 obtenção de dados de temperatura e sua respectiva disseminação na Internet; Especificar formalmente e implementar um “software” para aquisição remota de temperatura via Internet; Especificar formalmente e iniciar implementação de um sistema de informação WEB para gerar estatísticas, relatórios e gráficos relacionados ao comportamento da temperatura, possibilitando o monitoramento remoto e em tempo real desse parâmetro.

1.4. METODOLOGIA Inicialmente foi feito um estudo sobre a Internet embarcada e as possíveis arquiteturas e componentes que dão suporte a essa tecnologia. Neste momento foi escolhida a solução 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 teórico e prático sobre microcontroladores envolvendo sua programação e interfaceamento com periféricos, 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 conexão em rede Ethernet. Em seguida, foi realizado um estudo sobre programação concorrente e distribuída para a implementação do “daemon” para aquisição remota de temperatura. Este “software” se faz necessário, quando o circuito é utilizando como um sistema de aquisição e disponibilização de dados de temperatura via Internet. O “daemon” é o responsável por receber os dados de temperatura, armazenar no banco de dados e em arquivo de LOG e notificar a ocorrência de um alarme via “e-mail”. Posteriormente, foi estudada a tecnologia Java para WEB e seus conjuntos de “framework” para geração de gráficos, relatórios e armazenamento de informação em banco de dados. Essas tecnologias foram utilizadas para iniciar o processo de implementação do sistema de informação, que é responsável por permitir o monitoramento de temperatura através da WEB.

3

1.5. ESTRUTURA No capítulo 2 é apresentada a tecnologia Internet embarcada, bem como algumas soluções de “hardware” existentes no mercado. No capítulo 3 são apresentados os componentes de “hardware” especificados para utilização no presente trabalho. No capítulo 4 é apresentado o projeto dos circuitos para monitoramento de temperatura e para disponibilização dos dados via Internet. No capítulo 5 é apresentada a metodologia, considerações teóricas e especificação formal em UML relativas ao “daemon” para aquisição remota de temperatura via Internet. No capítulo 6 é apresentada a metodologia, considerações teóricas e especificação formal em UML relativas ao sistema WEB. Por fim, no capítulo 7 são feitas breves considerações sobre alguns parâmetros de desempenho em rede, avaliados em simulação, do circuito microcontrolado para monitoramento de temperatura e disponibilização dos dados via Internet.

4

2. INTERNET EMBARCADA Neste capítulo é feita uma breve apresentação da tecnologia Internet embarcada, suas aplicações e algumas plataformas de “hardware” para desenvolvimento de projetos utilizando a Internet embarcada.

2.1. INTRODUÇÃO A Internet embarcada nada mais é do que uma tecnologia que permite a conexão de sistemas embarcados à Internet, especialmente microcontroladores e DPS (Processadores Digitais de Sinais). Geralmente, isso é feito através da implementação de pilhas de comunicação, 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 é necessária para realizar a conexão física do sistema embarcado com um segmento de rede. O controlador Ethernet é o responsável por codificar, no padrão Ethernet, as informações recebidas/enviados do microcontrolador ou DSP. Já a pilha TCP/IP é utilizada para ser embarcada (gravada) na memória não-volátil (Flash) do microcontrolador, a fim de estabelecer a conexão lógica com uma máquina remota em um determinado segmento de rede.

2.2. APLICAÇÕES A Internet embarcada é muito utilizada para possibilitar o monitoramento e acionamento remoto (WOOD, 2007A), (WOOD, 2007B) e (WOOD, 2007C) . Por exemplo, é perfeitamente possível se construir um “hardware” utilizando Internet embarcada, que é conectado a um segmento de rede e possui um conjunto de páginas HTML, que permitem que dispositivos conectados ao mesmo sejam controlados (habilitados ou desabilitados) remotamente e em tempo-real. Para efetuar esse controle, o usuário necessitaria apenas de conexão com a Internet e de um navegador WEB, para acessar as páginas HTML armazenadas no “hardware”. Outra possibilidade é utilizar o “hardware” para fazer monitoramento remoto, ou seja, o mesmo obtém informações de um ambiente e disponibiliza as mesmas via Internet. O presente trabalho está inserido nesse último contexto de aplicação. Antigamente, para se fazer monitoramento ou acionamento remoto, utilizava-se um computador e uma placa de aquisição de dados. Esse modelo pode ser visto na Figura 2.1. Através do mesmo é possível 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 específica que se comunica com o computador, através de uma interface RS-232 ou USB, por exemplo. O servidor dedicado possui um servidor WEB, páginas HTML, o “driver” para comunicação com a placa e o programa de aplicação do usuário para fazer o monitoramento ou acionamento. Nesse modelo, o servidor WEB é utilizado para publicar as páginas HTML na Internet. As páginas HTML são utilizadas como interface para o usuário interagir com a placa, enquanto o programa de aplicação é responsável por identificar que ação o usuário executou na página e realizar o respectivo tratamento, que envolve a utilização do “driver” para estabelecer a comunicação e realizar na placa a ação solicitada pelo usuário. Quando se utiliza Internet embarcada para fazer monitoramento ou acionamento, o modelo é radicalmente modificado e o servidor dedicado não é mais necessário. 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 páginas HTML e o programa de aplicação estão armazenados na própria placa e o “driver” de comunicação com o computador, naturalmente, não é mais necessário. 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. 6

2.3. PLATAFORMAS EXISTENTES PARA INTERNET EMBARCADA Essa seção apresenta algumas plataformas de “hardware” existentes no mercado com suporte à tecnologia Internet embarcada.

2.3.1. PICDEM.NET 2 É uma placa de desenvolvimento para soluções 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 utilização com a pilha TCP/IP para microcontroladores e DSPs da Microchip, já que tanto a pilha quanto a plataforma são produzidos pela mesma empresa, minimizando assim problemas de incompatibilidade. Algumas características dessa placa são: • • • • • • • • • •

Servidor WEB com suporte a HTML; Total suporte à pilha TCP/IP da Microchip; Duas interfaces Ethernet (conector RJ-45); Conector para circuitos de expansão; “Display” alfa-numérico de 16x2 caracteres; Conector para programação e depuração no circuito (“in circuit”); Botões e LEDs programáveis; Sensor de temperatura; Interface RS-232/RS-485; Relógio 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.

7

2.3.2. EXPLORER16 BR PIC24FJ128GA010-I/PT É uma plataforma para desenvolvimento de soluções 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 à família PIC 24F, que são caracterizados por serem de 16 bits e possuírem alto poder de processamento. Algumas das características dessa placa são: • • • • • • • • • • • •

Microcontrolador PIC24FJ128GA010 da Microchip; Teclas e LEDs (4 teclas e 8 LEDs); Memória serial EEPROM 24WC256 (protocolo I2C); Memória serial EEPROM 25LC256 (protocolo SPI); Sensor de temperatura MCP9700 (saída analógica); Comunicação serial RS232; Comunicação CAN; Comunicação Ethernet; Botão de reset manual; Possibilidade de trabalhar com LCD 16x2 (alfanumérico) e LCD 128 x 64 (gráfico). OBS.: LCDs não inclusos; Compatível 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.

8

2.3.3. MAGICPIC BOARD É uma plataforma para desenvolvimento de soluções Ethernet/Internet e USB 2.0 fabricada pela empresa brasileira “Microgenius” (MICROGENIUS, 2008A). A plataforma utiliza o PIC 18F4550, que possui bloco interno para comunicação USB 2.0 e o controlador Ethernet ENC28J60. Algumas das características dessa placa são: • • • • • • • • • • • •

Controle de displays LCD alfanumérico 16X2 (16 colunas por 2 linhas ) no modo 4 bits; 4 teclas de acesso direto; 4 leds para controle lógico visual; 2 relés NA/NF para acionamento de cargas externas de 10A / 220V; Canal USB 2.0 para comunicação USB (necessário usar PIC18F4550); Espaço físico para soldar memória serial E2PROM 25c512; 1 trimpot para simulação e programação do canal A/D do PIC Microcontrolador PIC18F4550 DIP com 32Kbyte de Flash; Canal de gravação ICSP: Conector para modo depuração; Regulador de tensão; Controlador Ethernet ENC28J60; Entrada para Cartão 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.

9

2.3.4. DSPIC SIGMA 128 É uma plataforma fabricada pela empresa brasileira “Exsto” (EXSTO, 2009A) para processamento de sinais, que possui capacidade de conexão Ethernet/Internet. Utiliza o DSP dsPIC33FJ128GP706 da Microchip e o controlador Ethernet ENC28J60. Algumas das características dessa placa são: • • • • • • • • • • • • •

Utiliza o DSP dsPIC33FJ128GP706 da Microchip; Memória Flash de 8 Mega bits; 08 Leds de uso geral; 03 Chaves pulsativas; 03 Chaves Dip-Switch; 01 Botão de Reset; 02 Saídas de PWM; 04 Entradas analógica; Saídas para “display” alfanumérico e gráfico; 01 Interface serial; 01 controlador Ethernet baseado no ENC28J60; Codificador e Decodificador de áudio; Conectores de expansão.

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 capítulo descreve os principais componentes eletrônicos utilizados no “hardware” do projeto. Inicialmente é feita uma breve descrição sobre os microcontroladores da família PIC 18 F. Em seguida, são descritos os microcontroladores PIC18F2620 e PIC18F4620, que foram os microcontroladores utilizados até o momento para montagem do circuito de monitoramento de temperatura e simulação dos circuitos com conexão em rede Ethernet. São feitas considerações sobre esses microcontroladores em relação a recursos, capacidade de memória, periféricos, características elétricas, recursos especiais da CPU, arquitetura interna, pinagem, organização da memória, ciclos de máquina e configuração de oscilação. Além disso, são apresentados, de forma breve, os periféricos do microcontrolador utilizados no projeto: E/S digital, conversor A/D (Analógico/Digital), “Timer” e Módulo MSSP (Master Synchronous Serial Port) no modo SPI (Serial Peripheral Interface). Outros componentes importantes utilizados no projeto também são 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 são fabricados pela Microchip (MICROCHIP, 2008A) e pertencem à família PIC 18. Os microcontroladores dessa família são ideais para aplicações que necessitam de processamento a 10-16 MIPS (Milhões de Instruções por Segundo). Os mesmos possuem até 128KB de memória de programa e uma faixa de 18-100 pinos. Além disso, são otimizados para executar códigos gerados por compiladores da linguagem “C” (especialmente o C18 da Microchip), possuem 16 “bits” de palavra de programa e um conjunto de periféricos, tais como: E/S digitais, PWM (Pulse Width Modulation), USART (Universal Synchronous Receiver Trasmitter), entradas analógicas, MSSP (Master Synchronous Serial Port), dentre outros. A família PIC 18 também permite a implementação em “firmware” de tecnologias como USB, ZigBee, Ethernet e CAN e/ou utilização, em conjunto, de um microcontrolador PIC 18 com “chips” externos que implementam essas tecnologias. Para a utilização no “hardware” do projeto foram selecionados três microcontroladores da família PIC 18: 18F2620, 18F4620 e 18F4685. Na seção a seguir são descritas as principais características 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 elaboração de simulações de circuitos com conexão Ethernet.

11

3.1.1. CARACTERÍSTICAS Os microcontroladores PIC 18F2620 e PIC 18F4620 apresentam características muito parecidas. Mas o PIC 18F4620 é mais adequado, quando a quantidade de interfaces E/S do 18F2620 não é suficiente para uma determinada aplicação. Além disso, como são microcontroladores muito similares, o uso dos mesmos pode ser intercambiável. As principais características desses microcontroladores são:             

Memória de programa “Flash” com 64K Bytes; Memória EEPROM de 1024 bytes; Memória SRAM de 3986; Multiplicação por “hardware”; Processamento a 10 MIPS; Mais de 19 fontes de interrupção; Oscilador RC Interno; Interrupções com prioridade; USART; MSSP (modo SPI e I2C); Conversor A/D (Analógico/Digital); 4 Temporizadores; E/S Digital;

Uma das principais vantagens desses microcontroladores consiste no tamanho de sua memória de programa. Na prática, 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 memória de programa. Além disso, os mesmos possuem uma quantidade significativa de memória volátil (SRAM) e é nesta memória que os resultados temporários de cálculos ou leituras de E/S são armazenados. Esses microcontroladores também implementam uma memória não volátil do tipo EEPROM de 1024 bytes, possibilitando assim que alguns dados possam ser recuperados, mesmo após um desligamento do circuito onde o microcontrolador está inserido. Na Tabela 3.1 podem ser verificadas algumas características desses microcontroladores em relação aos tipos de memória utilizadas internamente. Pode-se perceber que em relação à capacidade de memória o PIC18F2620 e PIC18F4620 são idênticos.

12

Tabela 3.1 - Capacidade de memória dos microcontroladores PIC18F2620 e PIC18F4620. Microcontrolador

Memória de Programa

Memória de Dados

Flash

Instruções

SRAM

EEPROM

(bytes)

(em words)

(bytes)

(bytes)

PIC18F2620

64K

32768

3986

1024

PIC18F4620

64K

32768

3986

1024

Na Tabela 3.2 podem ser verificadas algumas características desses microcontroladores em relação à disponibilidade de periféricos. Percebe-se que o PIC18F4620 possui mais E/S, canais de conversão A/D e possui um módulo 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 módulo MSSP.

Tabela 3.2 - Periféricos dos microcontroladores PIC18F2620 e PIC18F4620. Microcontrolador

I/O

10-bit A/D (ch)

CCP/ECCP

MSSP

EUSART

(PWM)

SPI

I2C

Timers 8/16-bits

PIC18F2620

25

10

2/0

Sim

Sim

1

1/3

PIC18F4620

36

13

1/1

Sim

Sim

1

1/3

Esses microcontroladores possuem também alguns recursos especiais relacionados à CPU (Unidade Central de Processamento). São eles: •

“Power-on Reset (POR)”: faz com que o microcontrolador ao ser ligado seja mantido em estado de “reset”, até que a tensão VDD (tensão de alimentação do circuito) atinja um nível mínimo aceitável para operação;

•

“Brown-out Detect (BOD)”: faz com que o microcontrolador seja “resetado”, se a tensão de alimentação VDD cair abaixo de um determinado nível que pode ser configurado via programa;

•

“Power-up Timer (PWRT)”: causa um “delay” de aproximadamente 65.6 ms, que mantém o microcontrolador em estado de “reset” após 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 após o término do “delay” do PWRT, a fim de assegurar que o oscilador tenha sido inicializado corretamente e esteja estável, antes do microcontrolador sair do estado de “reset”;

•

“Watchdog timer (WDT)”: é um recurso que pode ser muito útil para garantir restrições de tempo e prevenir o travamento do microcontrolador na execução de determinada tarefa. Consiste em um “timer” progressivo que “resetará” o microcontrolador, cada vez que estourar seu limite máximo. Logo, em uma operação normal, o microcontrolador deve zerar esse “timer” periodicamente, para não ocorrer o estouro. Se o “watchdog” não 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 operação, mesmo na ocorrência de uma falha no oscilador externo, o que ocasiona automaticamente a mudança da configuração de oscilação 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. Além disso, como o barramento entre a CPU e a memória 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 instruções, que levam aproximadamente a mesma quantidade de tempo para serem executadas. Na seção anterior foi informado que os microcontroladores possuíam 64KB de memória de programa. Na verdade, observando a Figura 3.1, percebe-se que o barramento de programa é de 16 “bits”, logo a quantidade real de memória de programa seria de 32KW, já que a organização da mesma é em “words” (16 “bits”) e não em “bytes” (8 “bits”). Na Figura 3.1 são selecionados alguns subitens importantes da arquitetura interna e são feitas as considerações a seguir: 1. As vias de comunicação do microcontrolador com possíveis periféricos externos estão ligadas ao barramento de dados. Dessa forma, é possível, por exemplo, ler o valor de um sensor ou acionar uma saída através de um programa armazenado na memória de programa do microcontrolador; 2. Os periféricos do microcontrolador (memória EEPROM, “Timers”, MSSP, CCP, dentre outros) estão também ligados ao barramento de dados e compartilham recursos do microcontrolador entre si. Dessa forma, alguns periféricos só podem ser utilizados em detrimento de outros; 14

3. O barramento de instruções é de 16 “bits”, sendo dessa forma, uma palavra de 16 bits (“word”) a unidade de armazenamento da memória de programa e não “bytes”. É através deste barramento que é lido o programa armazenado no microcontrolador; 4. O barramento de dados é de 8 “bits”, dessa forma a ULA (Unidade Lógica Aritmética) e o microcontrolador são caracterizados por operarem sobre 8 “bits”. Além disso, a maior variável de um programa armazenado no microcontrolador pode ser apenas de 8 “bits”; 5. Existem 21 vias para endereçar a memória de programa “Flash” do microcontrolador. Como 2²¹ é igual a 2M “bytes” ou 1M “word”, essa é a quantidade máxima possível de memória de programa nesta arquitetura; 6. Os microcontroladores possuem uma pilha de 31 níveis, que é um recurso utilizado na chamada de procedimentos. A quantidade de níveis implica na quantidade de procedimentos que um programa pode fazer em cascata. Em geral, programas muito complexos são formados por um conjunto de procedimentos que podem ser chamados em cascata. Dessa forma, ter uma quantidade elevada de níveis permite que se tenha flexibilidade na divisão de um programa complexo em pequenas tarefas; 7. Estes microcontroladores podem possuir até 4KB de memória de dados RAM, pois existem 12 vias que permitem endereçar este espaço de memória. Os 4KB são justificáveis já que 2¹² é igual 4096; Além dos subitens comentados acima, outras características importantes podem ser observadas na Figura 3.1, como uma unidade dedicada a multiplicação 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 saída como quanto entrada de dados. Os pinos de E/S dos microcontroladores PIC18F2620 e PIC18F4620 estão divididos em 4 e 5 grupos respectivamente, denominados PORTs (portas). Estes PORTs são 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 específico 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 número de 0 a 7. Dessa forma, RA7, RC5 e RB2 são exemplos de nomes de pinos nos microcontroladores em questão. Em geral, nos microcontroladores PIC, além da função básica de E/S um pino pode ter funções mais avançadas, como por exemplo, uma saída PWM ou um canal de leitura A/D. Estas funções adicionais, quando configuradas, fazem com que os pinos em questão percam a função básica de E/S e passem a operar na função especial configurada para o mesmo. Por exemplo, o pino 3 dos microcontroladores cujo nome é RA1/AN1, além de possuir a função básica de E/S, também pode ser uma entrada analógica. Em geral, esse mesmo conceito se aplica aos demais pinos dos microcontroladores PIC, variando apenas a funcionalidade especial associada a cada pino básico de E/S.

Figura 3.2 - Pinagem do microcontrolador PIC18F2620.

17

Figura 3.3 - Pinagem do microcontrolador PIC18F4620.

3.1.4. CARACTERÍSTICAS ELÉTRICAS Algumas características elétricas destes microcontroladores podem ser verificadas na Tabela 3.3. Tabela 3.3 - Características elétricas dos microcontroladores PIC18F2620 e PIC18F4620.

Características

Faixa de Operação

Tensão de operação

2.0 V até 5.5 V

Voltagem em qualquer pino com exceção de VDD e MCLR

- 0.3V até (Vdd + 0.3V)

Voltagem do MCLR em relação a Vss

0 V até +13.25V

Voltagem do VDD em relação a Vss

- 0.3V até +7.5V

Dissipação total de energia

1.0 W

Corrente máxima por pino

25 mA

Corrente máxima de todos PORTs

200 mA

Freqüência máxima de operação

40 MHz

Temperatura de operação

-40°C até + 125°C

18

3.1.5. CICLOS DE MÁQUINA Para que esses microcontroladores possam executar um ciclo de máquina, são necessários 4 pulsos de “clock” da fonte de oscilação do sistema, já que internamente o microcontrolador possui um “pipeline” de 4 estágios. O ciclo de máquina é o tempo necessário para que o microcontrolador possa executar uma única instrução. Em geral, nos microcontroladores da família 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 estarão operando internamente na freqüência de 1 MHz (ou 1 MIPS). Entretanto, mais importante que a freqüência interna é o período dessa freqüência (o inverso da mesma), que é equivalente ao tempo de duração de um ciclo de máquina. Logo, para um “clock” externo de 4 MHz, o ciclo de máquina será 1µs. Considere uma nova configuração: supondo um cristal de 20 MHz, o microcontrolador operará a 5 MHz (freqüência externa divida por 4) e a 5 MIPS e seu ciclo de máquina será de 200 ns (inverso da freqüência). Percebe-se que, ao aumentar o “clock” externo, a velocidade de processamento MIPS também aumenta, logo são duas grandezas relacionadas e, em geral, diretamente proporcionais. Além disso, foi visto na seção anterior que a freqüência máxima de operação desses microcontroladores é de 40MHz, logo os mesmos podem operar a até 10 MIPS.

3.1.6. ORGANIZAÇÃO DA MEMÓRIA DE PROGRAMA Conforme informado anteriormente, estes microcontroladores apresentam 64 KB ou 32 KW de memória de programa do tipo “Flash”. A organização dessa memória 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 endereço hexadecimal 0x0000, que é o endereço inicial utilizado pelo microcontrolador para execução, quando o mesmo é ligado ou reiniciado (“resetado”). Em seguida, pode ser observado o endereço 0x0008, que é chamado de vetor de interrupção alta, e o endereço 0x0018 corresponde ao vetor de interrupção baixa. Através desses vetores de interrupção podem ser atribuídas prioridades às interrupções utilizadas. Após o vetor de interrupção baixa pode ser observado o inicio da memória de programa que termina no endereço 0xFFFF. É nesta última região de memória que o programa gravado no microcontrolador fica armazenado. A partir do endereço final da memória de programa se encontra uma região de memória não implementada nestes microcontroladores, que é identificada na Figura 3.4 pela região escura com o termo “Read ‘0’”. Além disso, esses microcontroladores podem endereçar até 2 Mbytes devido o contador de programa possuir 21 “bits”. O tipo de memória e esquema utilizados pelos microcontroladores PIC são muito adequados para o desenvolvimento de protótipos, pois a mesma é regravável até 100.000 vezes e é apagada eletricamente. Além disso, uma das grandes vantagens de utilizar um microcontrolador PIC como os da família 18 é que eles permitem gravação de programa no modo “In-Circuit”. Na prática isto significa que o microcontrolador pode ser gravado no próprio 19

circuito de protótipo, não sendo necessária a retirada do microcontrolador do circuito para gravá-lo.

Figura 3.4 - Mapa da memória de programa e pilha dos microcontroladores PIC18F2620/PIC18F4620

3.1.7. ORGANIZAÇÃO DA MEMÓRIA DADOS A memória dos microcontroladores PIC18F2620 e PIC18F4620 é do tipo RAM (Random Access Memory) estática (SRAM) e é divida em dois grupos: SFR (Special Function Register ou Registrador de Função Especial) e GPR (General Purpose Register ou Registrador de Propósito Geral). Os registradores do tipo SFR são utilizados para que o usuário altere configurações do microcontrolador em relação aos seus periféricos (“timer”, conversor A/D, PWM). Em geral, essa mudança é feita através da escrita de valores binários nesses registradores, assim o microcontrolador automaticamente lê esses registros e passa a operar da maneira desejada. Já os registradores do tipo GPR são utilizados para armazenar valores temporários relativos ao programa armazenado no microcontrolador, como por exemplo, o resultado de cálculos. Esse espaço possui tamanho de 3968 bytes. Na Figura 3.5 (MICROCHIP, 2008C) pode ser vista a memória de dados desses microcontroladores. A mesma é composta por 16 bancos com 256 bytes cada. Os 15 primeiros bancos de memória são 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. Além disso, esses microcontroladores dispõem de 1024 bytes de memória não-volátil que estão organizados do endereço 0x0000 a 0x03FF. 20

Figura 3.5 - Memória de dados dos microcontroladores PIC18F2620/PIC18F4620.

21

Figura 3.6 - Registradores de Função Especial (SFR) dos microcontroladores PIC18F2620/PIC18F4620.

3.1.8. CONFIGURAÇÕES DO OSCILADOR Os microcontroladores PIC18F2620 e PIC184620 podem utilizar 10 configurações de oscilação distintas. Entretanto, neste documento é abordada apenas a configuração “oscilador a cristal ou ressonador cerâmico”, que foi a configuração utilizada na montagem do circuito de monitoramento de temperatura e nas simulações dos circuitos com conexão Ethernet. Nos modos de oscilação LP (“Low Power”), XT (“XTAL”) e HS (“High Speed”), um cristal ou ressonador cerâmico é conectado nos pinos OSC1 e OSC2 dos microcontroladores, para estabelecer a oscilação, como pode ser visto na Figura 3.7 (MICROCHIP, 2008C). Há dois capacitores ligados em paralelo com o “terra” junto ao cristal. A função deles é garantir a estabilidade da fonte de oscilação. A principal diferença entre os modos LP, XT e HS está na freqüência 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 relação entre a freqüência do cristal, modo de oscilação e os capacitores necessários.

22

Figura 3.7 - Conexão entre o cristal e o microcontrolador na configuração "Oscilador a Cristal".

Tabela 3.4 - Relação entre o modo de oscilação, a freqüência do cristal e os capa citores necessários.

Tipo de Oscilador

Freqüência do Cristal

LP XT

HS

Valores testados

de

capacitores

C1

C2

32KHz

30pF

30pF

1 MHz

15pF

15pF

4 MHz

15pF

15pF

4 MHz

15pF

15pF

10 MHz

15pF

15pF

20 MHz

15pF

15pF

25 MHz

15pF

15pF

3.1.9. PERIFÉRICOS Nesta seção são feitas breves descrições dos periféricos utilizados pelos microcontroladores no desenvolvimento do projeto, seja para o monitoramento de temperatura ou para possibilitar a conexão 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 seção 3.1.3. Alguns pinos de E/S são multiplexados com funcionalidades alternativas providas por diversos periféricos integrados ao microcontrolador. Em geral, quando um periférico está habilitado, o pino corresponde não pode ser utilizado para E/S de propósito geral. Cada “port” possui três registradores associados à sua operação. São eles:   

Registrador TRIS (define o sentido do fluxo de dados – Entrada ou Saída); Registrador PORT (lê o nível do pino do microcontrolador); Registrador LAT (“latch” de saída).

O “Data LatchA” (registrador LATA) é utilizado em operações do tipo leituramodificação-escrita nos valores dos pinos de E/S do PORTA. Um modelo simplificado de um “port” genérico, sem interfaces de outros periféricos, pode ser visto na Figura 3.8 (MICROCHIP, 2008C). O PORTA é um “port” bidirecional de largura de 8 bits. A direção (entrada ou saída) do mesmo é definida pelo registrador TRISA. Ao atribuir o valor lógico “1” a um “bit” do TRISA o pino correspondente do PORTA opera como entrada, ficando este pino no modo de altaimpedância. Ao atribuir o valor “0” a um bit do TRISA faz com que o pino correspondente opere como saída, armazenado um valor no “latch” de saída do pino selecionado.

Figura 3.8 - Modelo genérico de PORT dos microcontroladores PIC18F2620 e PIC18F4620

24

Ao ler o PORTA, o que se lê são 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) é também mapeado na memória. Operações do tipo leitura-modificaçãoescrita no registrador LATA são leituras e escritas no valor armazenado no “latch” de saída do PORTA.

3.1.9.2. “TIMER” 0 O “Timer” 0 é um módulo que permite fazer temporizações e contagens no microcontrolador. Sua operação é definida via “software”, podendo atuar como contador ou “timer” em modo 8 ou 16 “bits”. Além 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 operação do módulo, incluindo a seleção de “prescaler” (recurso que permite contagem além 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 padrão 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 instrução. Mas o usuário pode escrever no TMR0 a fim de ajustá-lo, levando em consideração os dois ciclos “perdidos”. O modo contador do “Timer” 0 é selecionado através da atribuição 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 configuração 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 módulo conversor Analógico-Digital (A/D) possui dez entradas no PIC18F2620 e treze entradas no PIC18F4620. Esse módulo permite a conversão de um sinal de entrada analógico em um digital de dez “bits”. Fazem parte do módulo os cinco registradores a seguir:     

Registrador de resultado da parte alta da conversão A/D: ADRESH; Registrador de resultado da parte baixa da conversão 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 operação do conversor A/D, como por exemplo, o canal utilizado, o “status” da conversão, a habilitação do conversor, dentre outros. O registrador ADCON1 configura os pinos do “port” para a utilização com módulo A/D e a voltagem de referência utilizada pelo conversor. Já ADCON2 configura o formato do resultado (justificado a esquerda ou direita), tempo de aquisição e a freqüência (“clock”) da conversão. As tensões analógicas de referência utilizadas pelo microcontrolador podem ser internas (pinos de alimentação VDD e VSS) ou externas através dos pinos RA3/AN3/VREF+ e RA2/AN2/VREF-/CVREF. Além disso, esses microcontroladores possuem uma característica 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 conversão A/D deve ser gerado pelo oscilador RC interno do microcontrolador. A saída de um circuito “sample-and-hold” é utilizada como entrada para o conversor, que gera o resultado baseando-se na técnica de conversão “aproximações sucessivas”. Um “reset” no microcontrolador força todos os registradores para o estado de “reset”, inclusive os registradores de controle do conversor A/D. Conseqüentemente, o conversor A/D é forçado a se desligar e qualquer conversão em curso é abortada. 26

Cada pino de “port” associado ao conversor A/D pode ser configurado como entrada analógica ou digital. Os registradores ADRESH e ADRESL armazenam o resultado da conversão. Quando o conversor A/D conclui o processo de conversão, o resultado é carregado no par de registradores ADRESH:ADRESL, o “bit” GO/DONE do registrador ADCON0 é “resetado” e a “flag” de interrupção do conversor A/D (ADIF) é “setada”. O digrama de blocos do módulo conversor A/D pode ser visto na Figura 3.11 (MICROCHIP, 2008C).

Figura 3.11 - Diagrama de blocos do módulo conversor A/D.

3.1.9.4. MÓDULO MSSP O módulo MSSP (Master Synchronous Serial Port) implementa uma interface serial utilizada para comunicação com outros dispositivos periféricos ou microcontroladores. Esses dispositivos periféricos podem ser EEPROMs seriais, registradores de deslocamento, controladores de display, conversores A/D, dentre outros. O módulo MSSP pode operar em um dos dois modos a seguir:  

SPI (Serial Peripheral Interface); I2C (Inter-Intergrated Circuit);

O módulo MSSP possui três registradores associados: SSPSAT (registrador de “status”), SSPCON1 e SSPCON2 (registradores de controle). O uso desses registradores e a configuração individual dos seus “bits” variam de forma significativa, dependendo do modo (SPI ou I2C) que o módulo MSSP está operando. No modo SPI é permitido a transmissão e recepção síncrona de dados de 8 “bits” simultaneamente. Todos os 4 modos SPI são suportados. Para realizar a comunicação SPI, tipicamente três pinos são utilizados: 27

• Saída 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 módulo MSSP está operando no modo SPI, o mesmo possui quatro registradores associados. São eles: • Registrador de controle 1 MSSP (SSPCON1); • Registrador de “status” MSSP (SSPSTAT); • Registrador “buffer” serial de transmissão/recepção (SSPBUF); • Registrador de deslocamento MSSP (SSPSR) – não é acessível diretamente; Os registradores SSPCON1 e SSPSTAT são utilizados no modo SPI para controle e “status”, respectivamente. O registrador SSPSR é um registrador de deslocamento utilizado para o deslocamento dos dados de saída ou entrada. O SSPBUF é um registrador “buffer” onde os “bytes” de dados são lidos e escritos. Em operações de recepção, SSPSR e SSPBUF são 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 interrupção SSPIF é setada. Já durante a transmissão, o SSPBUF não está no formato “double-buffer”. Uma escrita em SSPBUF escreverá em ambos registradores (SSPBUF e SSPSR). Resumindo, o módulo MSSP consiste basicamente de registradores de deslocamento de transmissão/recepção (SSPSR) e de um registrador “buffer” (SSPBUF). O SSPSR desloca o dado para a saída 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. Então, o “bit” BF (“buffer” cheio) do registrador SSPSTAT e o “bit” de “flag” de interrupção (SSPIF) é “setado”. Quando o SSPBUF opera no modo “double-buffer” a recepção do próximo “byte” pode ser iniciada antes da leitura do dado que acabou de ser recebido. Qualquer escrita no registrador SSPBUF durante a transmissão/recepção de dados será ignorada e o “bit” de colisão na escrita WCOL é “setado”. O software do usuário deve “resetar” e monitorar o “bit” WCOL para poder determinar se a escrita no registrador SSPBUF foi realizada com sucesso. Quando o “software” de aplicação do usuário espera a recepção de um dado válido, o SSPBUF deve ser lido antes que o próximo “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 transmissão está completa. Quando o SSPBUF é lido, o “bit” BF é “resetado”. Esse dado não é relevante quando o SPI está operando apenas em modo de transmissão. Geralmente, a interrupção do módulo MSSP é utilizada para determinar quando uma transmissão/recepção foi concluída, então o SSPBUF deve ser lido e/ou escrito. Se o método da interrupção não é utilizado, então o software de aplicação pode fazer “polling” para garantir que uma colisão não ocorreu. A Figura 3.13 (MICROCHIP, 2008C) exibe uma comunicação entre interfaces SPI de dois microcontroladores. O controlador mestre inicia a transferência de dados através 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 transição 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 comunicação 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 tensão de saída linearmente proporcional à temperatura em graus Celsius, a taxa de 10mV para cada 1 °C de temperatura. Além disso, o LM35 apresenta vantagens em relação aos sensores de temperatura calibrados em “Kelvin”, já que não é necessário fazer a subtração de uma constante a partir do sinal de saída do sensor, para que se obtenha a relação em graus Celsius. O LM35 não necessita de qualquer calibração externa ou “trimming”, para fornecer com exatidão valores de temperatura com variações de 0,25 °C ou até 0,75°C na faixa de temperatura de -55°C a 150°C. O sensor também possui saída com baixa impedância, linear e calibração precisa, fazendo com que o interfaceamento de leitura seja simples. Este sensor pode ser alimentado por uma fonte simples ou simétrica, dependendo de como se deseja o sinal de saída. Mas, independente da fonte utilizada, a saída continuará sendo de 10mV/ °C, sendo drenada uma corrente de 60µA para a alimentação. A seguir apresenta-se um resumo das características do sensor:         

Calibrado diretamente em graus Celsius; Linear: +10.0 mV/ °C (fator de escala); 0,5°C de exatidão garantida (a 25 °C); Faixa de funcionamento de -55 °C a +150°C; Adequado para aplicações de monitoramento remoto; Baixo custo; Opera em tensões de 4 a 30 volts; Dreno de corrente menor que 60µA; Saída com baixa impedância: 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 configuração utilizada. Nesta configuração, o sensor mede temperaturas de +2 °C a +150°C.

Figura 3.14 - Encapsulamento do LM35 utilizado.

30

Figura 3.15 - Configuração em que o LM35 foi utilizado.

3.3. DISPLAY LCD Existem no mercado diversos tipos de “displays” LCD alfanuméricos que podem ser utilizados com microcontroladores. Em especial, os “displays” LCD com o controlador “Hitachi HD44780” são os mais populares e consolidados no mercado, tornando-se um padrão 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 comunicação (em paralelo) e necessita de uma fonte de alimentação simples para sua utilização. O “display” LCD é similar ao mostrado na Figura 3.16 (JHD204, 2005) .

Figura 3.16 - Display LCD JHD204.

A função associada e descrição dos pinos do “Display” LCD podem ser vistas na Tabela 3.5.

31

Tabela 3.5 - Pinagem do Display Dis play LCD JHD204.

Pino

Nome

Descrição

Função

1

Vss

Ground

0 V (GND)

2

Vcc

Alimentação do circuito

+5V

3

Vee

Ajuste no contraste do LCD

4

RS

Instrução / Seleção registrador de dados

5

R/W

Selação de leitura/escrita leitura/esc rita

do RS = 0: registrador de instrução; RS = 1: registrador de dados; R/W = 0: registrador de escrita; R/W = 0: registrador de leitura;

6

E

7

DB0

8

DB1

9

DB2

10

DB3

11

DB4

12

DB5

13

DB6

14

DB7

15 16

Sinal de habilitação

Entrada/ Saída de dados

8 bits: DB0 – DB7

LED+

Voltagem para o LED+

+5V

LED-

Voltagem para o LED-

0V

32

3.4. CONTROLADOR ETHERNET Basicamente, o objetivo principal de um controlador Ethernet é receber uma informação e gerar como resultado um dado equivalente codificado no padrão 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 padrão industrial SPI para comunicação serial com outros dispositivos. O ENC28J60 reúne todas as especificações IEEE 802.3 e incorpora um conjunto de esquemas de filtros de pacote para limitar a quantidade de pacotes que realmente necessitam ser processados. Além disso, o mesmo possui um módulo de DMA (Direct Memory Access) dedicado, para permitir uma maior vazão de dados e uma unidade de hardware dedicada para cálculo do “checksum”, que é uma informação para detecção de erro utilizada em diversos protocolos de rede. A comunicação com um controlador “host”, como por exemplo um microcontrolador, é implementada via pino de interrupção e interface SPI, a uma velocidade superior a 20MHz. Dois “leds” são 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 comunicação do controlador “host”, por exemplo um microcontrolador, com o ENC28J60; 2. Registradores de controle que são utilizados para controle e monitoramento do ENC28J60; 3. “Dual Port RAM buffer” para transmissão e recepção de pacotes de dados; 33

4. Árbitro para controlar o acesso ao RAM “buffer” quando requisições são feitas a partir da DMA e dos blocos de transmissão e recepção; 5. Uma interface de barramento que interpreta dados e comandos recebidos via interface SPI; 6. Módulo (ou camada) MAC (Medium Access Controller) que implementa o padrão IEEE 802.3; 7. Camada física (PHY) que codifica e decodifica o dado analógico presente na interface de par trançado. Esse controlador Ethernet também suporta outros blocos, como oscilador, regulador de tensão “on-chip”, dentre outros. Um típico circuito de aplicação do ENC28J60 pode ser visto na Figura 3.18 (MICROCHIP, 2008B) . Além do controlador, um transformador de pulso e alguns componentes passivos são necessários para conectar um microcontrolador a uma rede Ethernet.

Figura 3.18 - Típico circuito de aplicação do ENC28J60.

O esquema de oscilação utilizado foi baseado em cristal, através de um esquema similar ao discutido na seção 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 necessários para estabelecer uma interface Ethernet.

34

Os circuitos analógicos internos do módulo PHY necessitam de uma resistência externa de 2.32 KΩ, um resistor de 1% deve ser anexado do RBIAS à referência de terra. Esse resistor influencia na amplitude dos sinais TPOUT+/-. Dessa forma, esse resistor deve ser colocado o mais próximo possível do controlador, mas afastado das trilhas da placa de circuito impresso, a fim de evitar ruído capacitivo, que certamente afetaria o sinal de transmissão. Além disso, alguns dispositivos (ou componentes) de lógica digital internos ao controlador operam na tensão de 2.5 Volts. O próprio controlador possui um regulador de tensão interno para gerar essa voltagem. O único componente externo necessário é um filtro capacitivo, conectado do Vcap à referência de terra. Um transformador de pulso do tipo “1:1 center-taped” nos pinos TPIN+/TPIN- e TPOUT+/TPOUT é necessário para a operação Ethernet. O ENC28J60 foi desenvolvido para operar na tensão de 3.3 volts. De qualquer forma, ele pode facilmente ser integrado a um sistema (ou circuito) cuja tensão de alimentação seja 5 Volts. Os pinos da interface SPI CS, SCK, RESET e SI possuem tolerância 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 comunicação com o microcontrolador um sinal CMOS de 3.3 Volts, o microcontrolador não interpretará o sinal como nível alto correspondente à especificação SPI. Logo, é necessário um transdutor de nível 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 comunicação entre microcontrolador e ENC28J60 utilizando transdutor de nível 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 nível TTL “bufferizadas” podem ser utilizadas para fazer essa “conversão” de nível . Os “3-state” são 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 compatível com o padrão 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 capítulo descreve o processo de desenvolvimento do “hardware” e “software”. O capítulo é divido em duas partes: projeto de “hardware” e de “software”. Na seção projeto de ‘“hardware” é apresentada a metodologia utilizada e são descritas algumas decisões de projeto importantes. Em seguida, são apresentadas as principais ferramentas utilizadas. Os circuitos projetados são apresentados em simulação no Proteus VSM (LABCENTER, 2008) e são feitas considerações sobre os componentes utilizados e sobre o funcionamento desses circuitos. Na seção projeto de “software” são feitas considerações teóricas e de implementação relacionadas a cada “software” embarcado, em seguida são apresentados os fluxogramas e são feitas as respectivas descrições e considerações.

4.1. METODOLOGIA Inicialmente o desenvolvimento do sistema embarcado foi dividido em duas etapas: circuito para monitoramento de temperatura e circuito para conexão em rede Ethernet. Antes de iniciar o projeto desses circuitos, foram realizados estudos sobre os microcontroladores PIC da Microchip e a respectiva programação em linguagem C dos mesmos. Os estudos foram concentrados nos periféricos dos microcontroladores que são utilizados no “hardware” do projeto. Então, foram estudados os blocos de E/S digital, conversor A/D, módulo MSSP no modo SPI e o bloco de temporização “Timer” 0. Posteriormente, foram realizados estudos sobre programação em linguagem C desses recursos. Na fase anterior à fase de projeto dos circuitos, para fins de estudo, foram elaborados esquemas eletrônicos simples e os respectivos programas para a utilização dos periféricos que são utilizados no sistema microcontrolado. Os circuitos e programas desenvolvidos nessa fase de estudo foram: circuito para manipulação de E/S digital, entrada analógica, temporização com Timer 0 e interfaceamento com “display” LCD. Posteriormente, os esquemas eletrônicos e programas foram testados utilizando o simulador Proteus VSM, onde os esquemas e respectivos programas puderam ser validados. Após ter sido realizada a familiarização com os microcontroladores, sua programação e recursos, o circuito para monitoramento de temperatura foi desenvolvido, seguindo o processo de elaboração dos esquemas dos circuitos e respectivos programas e validação 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 união 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 básicos para manipulação de I/O digital, entrada analógica e interfaceamento com “display”. Essas 37

montagens iniciais foram feitas para permitir uma melhor familiarização com os equipamentos eletrônicos adquiridos (fonte de alimentação, gravador/depurador de microcontroladores, multímetro e “protoboard”) e os componentes eletrônicos (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 binário 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 documentação técnica e código-fonte da pilha TCP/IP (MICROCHIP, 2008) da Microchip que é específica para utilização 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 características do controlador, nos blocos internos, no esquema de comunicação com microcontroladores e no conjunto de componentes externos necessários ao seu funcionamento. Em seguida, foi estudado o MPFS (Microchip File System), que permite o armazenamento de dados em formato binário no microcontrolador e as funções do Microchip HTTP Server, relacionadas à geração de páginas HTML dinâmicas a partir do microcontrolador. Em seguida, foi elaborado um esboço do esquema eletrônico completo do sistema microcontrolado que é composto pelo circuito para monitoramento de temperatura e o circuito para conexão em rede Ethernet. Através da união desses dois circuitos é formado o circuito para monitoramento de temperatura e disponibilização dos dados via rede de computadores. Em seguida, assim como no projeto dos circuitos citados anteriormente, foi realizada a validação, 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 conexão de um “hardware” microcontrolado em rede perfeitamente, com funcionamento e dinâmica idêntica à de um hardware que utiliza a tecnologia Internet embarcada. Também se constatou que a montagem desse “hardware” levou muito tempo, não pela dificuldade da montagem, mas principalmente pela dificuldade de aquisição de peças e componentes no mercado nacional, já descartando o mercado local. Tentou-se comprar a interface de rede, por exemplo, inicialmente fora do país, mas não houve resposta da empresa responsável; três meses depois a mesma passou a ser comercializada no Brasil, sendo adquirida um mês depois. Além da própria interface de rede, mais difícil ainda foi encontrar, em curto prazo, os componentes passivos (indutores e resistores), que são específicos para utilização com o controlador ENC28J60, sendo os responsáveis pela geração do sinal no padrão “Ethernet”, ou seja, de importância fundamental para o sistema embarcado. Como o sistema embarcado é apenas um dos componentes integrantes do projeto e sua especificação completa já havia sido definida, o foco do projeto passou então a ser os demais programas e sistemas necessários para o projeto, que não haviam ainda sido desenvolvidos, já que sua importância e utilidade são dependentes da existência do sistema embarcado e da sua capacidade de disponibilizar os dados via rede de computadores. A simulação foi utilizada como ferramenta de apoio quando o 38

sistema embarcado era necessário, como por exemplo, no processo de desenvolvimento da página HTML embarcada no microcontrolador e na comunicação remota com o “daemon” de aquisição de dados.

4.2. FERRAMENTAS UTILIZADAS Essa seção apresenta, de forma breve, as principais ferramentas utilizadas no processo de desenvolvimento e especificação do sistema embarcado.

4.2.1. MPLAB IDE O MPLAB (MICROCHIP, 2008) é um IDE (Ambiente de Desenvolvimento Integrado) gratuito desenvolvido pela Microchip. Ele dispõem de um conjunto de ferramentas (editor, simulador, gravador, depurador e compilador) para o desenvolvimento de aplicações 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 fácil utilização e possui um conjunto de aplicativos para desenvolvimento e depuração de forma rápida e ágil de aplicações 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 programação “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 integração com ambiente integrado de desenvolvimento MPLAB IDE, permitindo depuração em nível de código com o “software” MPLAB e em nível de “hardware” com depuradores como o ICD2BR. A organização do projeto, opções de compilação e customização de arquivos “linker” pode ser toda feita pelo MPLAB IDE, que disponibiliza uma interface gráfica amigável para o compilador. Algumas características do compilador MPLAB C18 podem ser vistas a seguir:  



 



Compatibilidade com C ANSI ’89; Integração com o MPLAB IDE a fim de facilitar a gerência de projeto e a depuração em nível de código-fonte; Compatibilidade com o assembler MPASM, o que permite total liberdade para integração de código C e Assembly; Eficiente geração de código com múltiplos níveis de otimização; Uma grande biblioteca de funções para o usuário, incluindo PWM, SPI, I2C, USART, manipulação de “strings” e funções matemáticas; Disponibilidade de uma versão gratuita para estudantes.

4.2.3. PROTEUS VSM O Proteus (LABCENTER, 2008) é um conjunto de programas para o desenvolvimento de sistemas eletrônicos. Ele possui ferramentas para projeto de placas de circuito impresso (ARES), para criação de protótipos de circuitos (ISIS) e simulação animada de circuitos (VSM). O Proteus é o único “software” que oferece habilidade de co-simulação de sistemas microcontrolados, tanto em alto nível quanto em baixo nível integrado, ao simulador de circuitos SPICE. O Proteus VSM (Virtual System Modelling) combina uma integração com o simulador de circuitos SPICE, componentes animados e modelos de microprocessadores para facilitar a co-simulação completa de sistemas baseados em microcontroladores. A princípio é possível desenvolver e testar um projeto utilizando o Proteus VSM, antes mesmo de o protótipo físico estar construído. Isso é possível porque o Proteus VSM simula, através de animação em tempo real (ou bem próximo disso) a integração e funcionamento de todos os componentes de um projeto e oferece instrumentos virtuais (Osciloscópio, Multímetro, Analisador lógico, dentre outros) para depuração 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 família PIC 40

18F. Na Figura 4.3 pode ser vista a mesma placa em total simulação e animação no Proteus VSM.

Figura 4.2 - Placa PICDEM2+ da Microchip.

Figura 4.3 - Placa PICDEM2+ no ambiente ISIS e simulada através do Proteus VSM.

41

4.3. PROJETO DE “HARDWARE” Essa seção descreve o projeto, lista de componentes e funcionamento do circuito microcontrolado para monitoramento de temperatura e circuito microcontrolado para monitoramento de temperatura e disponibilização dos dados via conexão de rede. São mostrados os esquemas eletrônicos já em simulação no Proteus VSM e é feita uma breve descrição do funcionamento de cada um dos circuitos apresentados. Os circuitos projetados são componentes da arquitetura do “hardware” proposto. Um esboço da mesma pode ser visto na Figura 4.4.

Figura 4.4 - Esboço da arquitetura do "hardware" proposto.

O princípio de funcionamento do “hardware” proposto pode ser explicado utilizando como base as duas formas com que a temperatura estará disponível para visualização por parte do usuário: localmente e remotamente. Na primeira forma, o sensor de temperatura obtém o valor da temperatura ambiente e a transmite para o microcontrolador, que recebe este dado e, através de um conversor analógico/digital (ADC) interno, realiza a respectiva conversão e transfere o dado já no formato digital para ser exibido no display LCD. Já na segunda forma, o “hardware” é conectado através 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 comunicação entre o controlador Ethernet e o microcontrolador (MCU) é feita através do protocolo SPI, que é um protocolo utilizado para comunicação entre circuitos integrados. O microcontrolador (MCU) possui embarcada uma pilha TCP/IP (ver seção 4.4.4.1.1.), que permitirá a comunicação 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 serviços típicos da camada de aplicação, como: HTTP, FTP, SMTP, dentre outros. Além da pilha TCP/IP, o microcontrolador terá gravado em sua memória interna uma página HTML, que será apresentada ao usuário com a respectiva temperatura atual. Dessa forma, um usuário com conexão a Internet e através de um navegador WEB poderá visualizar, através de uma requisição HTTP, a temperatura no ambiente monitorado, bastando apenas acessar o IP do servidor microcontrolado através 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 visualização do mesmo no display LCD. Esse circuito pode ser visto na Figura 4.5.

Os componentes desse circuito são:  

  

Um microcontrolador PIC18F2620 (Componente U1 da Figura 4.5); Um display LCD compatível 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 - Simulação do circuito microcontrolado para monitoramento de temperatura.

O sensor de temperatura LM 35 mede a temperatura ambiente e gera uma tensão em mV proporcional a essa temperatura. Um fato importante é que na configuração que o LM35 está sendo utilizado, o mesmo medirá temperaturas na faixa de 2 °C a 150°C. De fato isso é uma limitação, mas para medir uma faixa mais ampla, incluindo valores negativos, seria necessário adicionar uma fonte simétrica ao circuito. Assim, essa capacidade adicional foi deixada para uma fase futura de melhorias no circuito. 43

Inicialmente o microcontrolador envia os textos estáticos “RNP – PoP-RN”, “Temperatura” e “C”. Em seguida o microcontrolador lê o sinal analógico gerado pelo sensor de temperatura LM 35, através do pino RA0, que está configurado como uma entrada analógica. Através do módulo conversor A/D interno, o microcontrolador converte o sinal para digital e o formata para exibição no “display”. Logo em seguida os dados são 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 28 °C. 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 DISPONIBILIZAÇÃO DOS DADOS ATRAVÉS DE CONEXÃO DE REDE O objetivo deste circuito é obter os dados de temperatura a partir de um sensor LM 35 e possibilitar a visão local (através do display LCD) e remota (através da “Internet”) desses dados. Esse circuito pode ser visto na Figura 4.7. Os componentes desse circuito são:  

   

Um microcontrolador PIC18F4620 (Componente U1 da Figura 4.7); Um “display” LCD compatível 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 - Simulação do circuito microcontrolado para monitoramento de temperatura e disponibilização dos dados via Internet.

Duas formas simples de explicar o funcionamento desse circuito, baseiam-se na maneira como a temperatura será visualizada pelo usuário: localmente ou remotamente. Quando o usuário deseja verificar a temperatura localmente, olhando para a placa, por exemplo, o processo é similar ao discutido na seção 4.3.1. Mas como esse circuito possui conexão 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 aplicação para o monitoramento de temperatura. Mas, basicamente, inicialmente é feita a inicialização da pilha TCP/IP e dos respectivos módulos utilizados, como por exemplo, o MAC, TCP, IP, HTTP, dentre outros. Após a pilha TCP/IP ser inicializada corretamente e o circuito microcontrolado já estar em rede, o passo seguinte é enviar o texto estático com as informações sobre o endereço 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 aplicação seja otimizado. Como os microcontroladores não possuem ainda capacidade “multithread”, há apenas um fluxo de execução no mesmo. Assim, se uma operação demorar, a mesma pode comprometer todo o desempenho do sistema e influenciando de forma negativa, ou até mesmo inviabilizando a conexão deste microcontrolador em rede, já que o mesmo não terá capacidade de processar de forma satisfatória os pacotes recebidos e responder aos clientes, antes que ocorra um “time-out” nos mesmos. Quando o usuário deseja visualizar os dados remotamente, o mesmo deve enviar uma requisição HTTP para o circuito microcontrolado, que está em rede e se comporta normalmente como um “host” nessa rede. Essa requisição pode ser feita através da digitação do IP (neste caso, 192.168.0.50) do circuito microcontrolado na URL de um “browser” (navegador), dessa forma o circuito vai interpretar a requisição do navegador do usuário e gerar, através de um servidor HTTP interno, uma página HTML de resposta ao usuário. Esta página contém o valor da temperatura lida pelo LM 35 no momento da recepção da requisição no microcontrolador. A página gerada pelo servidor HTTP microcontrolado pode ser vista na Figura 4.8.

Figura 4.8 - Página para monitoramento de temperatura gerada por um servidor HTTP microcontrolado. 46

O circuito apresentado na Figura 4.7 também pode ser utilizando com o “software” embarcado cliente TCP microcontrolado. A Figura 4.9 apresenta, em simulação, a comunicação 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 versão 7.2, que foi utilizada para elaboração da simulação, simplifica bastante o uso do controlador ENC28J60 e abstrai vários componentes que seriam necessários para o funcionamento do mesmo, como indutores, resistores, transformadores e todos os demais componentes comentados na seção 3.4. Dessa forma, esse esquema deve ser observado apenas para fins de simulação. Não deve ser utilizado como esquema para montagem de um circuito com conexão Ethernet, já que muitos componentes essenciais, necessários na montagem do circuito real, são abstraídos pelo simulador. A complexidade da simulação se concentra basicamente na configuração da pilha TCP/IP (que está embarcada no microcontrolador), de forma a permitir seu funcionamento com esse circuito. A Microchip não disponibiliza todas as configurações e variações possíveis para o uso da pilha TCP/IP com qualquer microcontrolador. Então, esse é um processo de configuração da pilha TCP/IP embarcada que depende muito do conhecimento do usuário sobre a arquitetura do microcontrolador, protocolo SPI, protocolos de rede e programação em C em baixo nível.

Figura 4.9 - Comunicação entre um cliente TCP microcontrolado e um servidor TCP remoto baseado em um PC.

47

4.4. PROJETO DE “SOFTWARE” Essa seção descreve os aspectos teóricos e de implementação dos diversos programas embarcados, desenvolvidos para utilização nos circuitos microcontrolados especificados na seção 4.3. São feitas considerações teóricas sobre os recursos utilizados dos microcontroladores, bem como as funções mais importantes utilizadas e os fluxogramas que descrevem esses programas.

4.4.1. “SOFTWARE” EMBARCADO PARA INTERFACEAMENTO COM SENSOR DE TEMPERATURA LM35 Essa seção descreve os aspectos teóricos de recursos e periféricos utilizados dos microcontroladores para interfaceamento com o sensor LM35. Inicialmente, são feitas considerações sobre teoria e uso de conversores A/D nos microcontroladores especificados. Além disso, são apresentadas as principais funções utilizadas na implementação do “software” e, em seguida, é apresentado um fluxograma que descreve essa implementação.

4.4.1.1. CONSIDERAÇÕES TEÓRICAS Os sensores de temperatura geralmente fornecem uma informação analógica, como por exemplo, tensão, que é proporcional à temperatura medida. Então, para essa temperatura ser internamente processada no microcontrolador, de forma a poder ser posteriormente exibida em um “display” ou conjunto de “leds”, é necessário o uso de um conversor A/D. Como visto no capitulo 3, os microcontroladores já dispõem de um internamente. A resolução da conversão depende da menor tensão lida pelo conversor A/D que produz variação correspondente na saída do mesmo, ou seja, é o menor valor que pode ser medido pelo conversor. A resolução pode ser calculada pela seguinte fórmula:

resolução =

tensãodere ferência

2 NúmeroDeBits

48

Cada um dos diversos “bits” que compõe a informação digitalizada é responsável por uma parcela do valor da informação analógica a ser convertida. Dessa forma, a soma da contribuição de todos esses “bits” forma a tensão de entrada do conversor A/D. Logo, a parcela de tensão de um determinado “bit” do conversor A/D pode ser determinada pela seguinte fórmula:

tensãodeentrada =

valordobit ∗ 2 (

bit −1)

2 NúmeroDebits

∗ tensãodere ferência

Percebe-se que apenas os bits de valor “1” representam alguma parcela da tensão analógica, já que os bits de valor “0” não contribuem para formar a tensão de entrada. Quanto maior a quantidade de bits, maior a exatidão e resolução do conversor. O PIC18F2620 utilizado nos circuitos que empregam o sensor LM 35 possui um conversor A/D interno de 10 bits. Existem diversas técnicas de conversão A/D, o PIC18F2620 utiliza a técnica de “aproximações sucessivas”. Nessa técnica a conversão é realizada do “bit” mais significativo para o menos significativo. O motivo dessa escolha é bem simples, o “bit” mais significativo já representa a metade da tensão de referência, conhecer o valor lógico desse “bit” já indica se a tensão de entrada é maior ou menor que a metade da referência. Em seguida, analisa-se o próximo “bit” mais significativo e o mesmo representa a ½ (metade) da metade da tensão de referência, o processo se repete até o “bit” menos significativo. Supondo, por exemplo, um conversor A/D de quatro bits com tensão de referência a 5 V, a tabela com a parcela de tensão de cada “bit” representa pode ser vista na Tabela 4.1

Tabela 4.1 - Parcela de tensão que cada "bit" representa em um conversor A/D de 4 “bits” com referência em 5 Volts.

Bit

Tensão

4

2,5 V

3

1,25 V

2

0,625 V

1

0,3125 V

49

Supondo que a tensão de entrada seja de 3,3 V. Neste caso os passos de conversão seriam os seguintes: 1. Testa-se o “bit” mais significativo, ou seja, a tensão de entrada é maior que 2,5 V? Sim, logo esse “bit” vale 1. 2. Teste-se o próximo “bit”, ou seja, a tensão de entrada é maior do que 3,75V (2,5V + 1,25V)? Não, portanto, este “bit” é 0. 3. Testa-se o próximo “bit”, ou seja, a tensão 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 tensão de entrada é maior do que 3,4375 (2,5V + 0,625V + 0,3125V)? Não, portanto, este “bit” é “0” e o valor binário da conversão é 1010. A vantagem dessa técnica de conversão é sua rapidez, já que para um conversor A/D de n “bits” são necessárias apenas n iterações, independente do valor a ser convertido. No caso anterior, como o conversor era de quatro “bits”, foram necessárias quatro iterações. Apesar de o PIC18F2620 possuir 11 canais analógicos como foi visto na seção 3.1.9.3, internamente só existe um módulo de conversão. Logo, apenas um canal pode ser utilizado por vez. Se forem necessários vários canais, a multiplexação do uso do conversor A/D deve ser definido pelo “software” embarcado desenvolvido pelo usuário. Como o microcontrolador possui 11 canais analógicos, deve-se definir, de acordo com o projeto, a quantidade de canais necessários. 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 não podem ser escolhidos individualmente, sendo necessário então verificar a Figura 4.10 e escolher a configuração que mais se adéqua ao projeto.

Figura 4.10 - Configurações possíveis dos canais A/D para o PIC18F2620.

50

A configuração dos canais analógicos utilizados é feita através dos quatro primeiros bits (registradores PCFG) do registrador de controle ADCON1. Além da configuração dos “bits” conforme a tabela apresentada, também é necessário configurar o registrador TRIS do PORT associado ao pino que se deseja utilizar como entrada analógica, definindo o mesmo com o valor “1”, que significa que esse pino será utilizado como entrada de dados. Outra informação importante disponível na tabela é no que diz respeito às tensões de referência. A conversão é realizada comparando-se a tensão de entrada com as tensões de referência Vref+ e Vref-. Logo, quando a tensão de entrada for igual a Vref+, a conversão resultará no valor máximo (1023) e quando a mesma for igual a Vref-, então o resultado da conversão será o valor mínimo (0). Com intuito de evitar problemas de ruído e variações da entrada analógica durante o processo de conversão, o microcontrolador utiliza o processo de “sample-and-hold (S-H)”. Internamente, o microcontrolador possui um capacitor de 25pF, que é conectado ao canal analógico em uso. Quando o processo de conversão propriamente dito é iniciado, o capacitor é desconectado automaticamente do canal analógico, dessa forma a tensão sobre o capacitor é mantida constante. A tensão analógica utilizada durante todo o processo de conversão é a existente nesse capacitor e não mais a do canal analógico. Logo, mesmo que a tensão no canal varie a conversão não é afetada. O processo de conversão A/D do microcontrolador possui 5 fases. São elas:

1. Adequação do capacitor: O capacitor, em geral, permanece o tempo todo ligado ao sistema de entradas analógicas, ficando desligado apenas durante o processo de conversão. Supondo que o mesmo esteja monitorando um canal com uma tensão que tende a zero e, posteriormente, seja “chaveado” para monitorar um canal que esteja com uma tensão de 5 V na entrada, o capacitor terá que ser completamente carregado com essa tensão, para que o processo de conversão possa ser iniciado. Obviamente, essa carga leva algum tempo: o tempo mínimo é de 1.4 µs para uma fonte de tensão analógica que possui a impedância mínima de 50 Ω e 2.4 µs para a impedância máxima indicada que é 2.5 KΩ. Percebe-se que esse tempo depende da impedância de entrada, mas também da diferença de tensão entre a entrada e o capacitor e da temperatura. Quanto menor a impedância menor o tempo de adequação.

2. Desligamento do capacitor: Depois do início do processo de conversão, o capacitor será desligado internamente do circuito de entrada. Esse processo é feito em aproximadamente 100 ns, sendo dessa forma, um valor praticamente desprezível.

51

3. Conversão: O tempo de conversão é um dado importante e está diretamente relacionado com a freqüência de trabalho do conversor A/D. Para que o sistema de conversão funcione, um sinal de “clock” deve ser aplicado ao conversor A/D. Cada período desse “clock” é chamado de TAD e representa o tempo de conversão de 1 “bit”. Como o conversor do microcontrolador é de 10 bits, são necessários 11 TAD no total, o TAD adicional é o tempo necessário decorrido entre a fase de adequação e o início do processo de conversão. O valor do TAD depende da freqüência empregada.

4. Religamento do capacitor: No final da conversão os registradores de resultado são atualizados com o respectivo valor da conversão, o valor da “flag” de interrupção é alterado e o capacitor é então desligado. O tempo mínimo recomendado para esse processo é de 2 TAD.

5. Nova adequação do capacitor: Durante o tempo de conversão, a tensão no capacitor não foi alterada. Mas no término do processo, o mesmo será novamente ligado na entrada analógica, que pode ter sofrido uma variação brusca de tensão devido à mudança de canal, por exemplo. Logo, no intervalo entre uma conversão e outra é necessário um tempo para uma nova adequação do capacitor, sendo recomendado o tempo máximo, que é de 2.4 µs, como foi visto no item “adequação do capacitor”, cujas informações também são válidas para este item.

Depois da configuração dos canais utilizados, é necessário realizar a configuração da freqüência de trabalho. Isso é feito através dos três primeiros “bits” do ACQT, que correspondem aos “bits” 3, 4 e 5 do registrador ADCON2. Como foi discutido anteriormente, a freqüência de trabalho está relacionada à freqüência de oscilação que está sendo utilizada pelo circuito, podendo a mesma ser gerada por um oscilador externo ou pelo oscilador RC interno do microcontrolador. Além disso, o “clock” utilizado pelo conversor A/D pode ser configurado via “software”. A freqüência de trabalho será igual à freqüência de oscilação 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 conversão A/D (TAD) deve ser o menor possível, mas deve estar entre os valores possíveis de TAD que são: 0.7µs e 25µs. A Tabela 4.2 apresenta uma relação entra a configuração dos “bits” do registrador de controle referente ao TAD, o fator de configuração do TAD correspondente a máxima freqüência possível que os osciladores do sistema podem utilizar para garantir a operação correta do conversor A/D.

52

Tabela 4.2 – Máxima freqüência possível para permitir a operação correta do conversor A/D.

“Clock” da conversão A/D

Máxima freqüência por dispositivo

Operação

ADCS2:ADCS0

PIC18F2X20/4X20

PIC18LF2X20/4X20

2 Tosc

000

2.86 MHz

1.43 KHz

4 Tosc

100

5.71 MHz

2.86 MHz

8 Tosc

001

11.43 MHz

5.72 MHz

16 Tosc

101

22.86 MHz

11.43 MHz

32 Tosc

010

40.0 MHz

22.86 MHz

64 Tosc

110

40.0 MHz

22.86 MHz

RC

X11

1.00 MHz

1.00 MHz

O último passo a ser configurado diz respeito à forma como o resultado da conversão 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 conversão, o capacitor interno é desligado do circuito de entrada e a conversão é executada em 11TAD e logo no próximo ciclo de máquina, os registradores ADRESH e ADRESL são 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 término da conversão. Além disso, o “flag” de interrupção PIR1 do registrador ADIF também é ativado. Caso seja atribuído o valor “0” ao registrador GO/DONE, a conversão será abortada e os registradores ADRESH e ADRESL não serão alterados.

4.4.1.2. CONSIDERAÇÕES DE IMPLEMENTAÇÃO A implementação do “software” embarcado foi feita na linguagem C (ANSI) e foram utilizadas as bibliotecas do compilador C18, que é o compilador específico da Microchip para os microcontroladores da família PIC 18.

53

A seguir é feita uma breve descrição das principais funções utilizadas, que se relacionam com o periférico conversor A/D do microcontrolador. As funções e respectivas considerações podem ser vistas na Tabela 4.3.

Tabela 4.3 - Descrição das principais funções do compilador C18 relacionadas ao conversor A/D.

BusyADC Descrição

Verificar se o conversor A/D está realizado uma conversão em determinado momento.

Biblioteca

adc.h

Protótipo

char BusyADC( void );

Observações

Essa função verifica se o periférico conversor A/D está no processo de conversão de um dado analógico.

Valor de retorno

1, Se o conversor A/D está realizando uma conversão. 0, Se o conversor A/D não está realizando nenhuma conversão.

CloseADC Descrição

Desabilita o conversor A/D

Biblioteca

adc.h

Protótipo

void CloseADC( void );

Observação

Essa função desabilita o conversor A/D e o mecanismo de interrupção A/D.

ConvertADC Descrição

Inicia o processo de conversão A/D

Biblioteca

adc.h

Protótipo

void ConvertADC( void );

Observação

Inicia o processo de conversão A/D, a função busyADC( ) deve ser utilizada para verificar o fim da conversão.

ReadADC 54

Descrição

Lê o resultado da conversão A/D.

Biblioteca

adc.h

Protótipo

int ReadADC( void );

Observação

Essa função lê um valor de 16 “bits” que representa o resultado da conversão A/D.

Valor de retorno

Essa função retorna o um valor de 16 bits. Dependo da configuração do conversor A/D, o resultado poderá conter o resultado nos 16 bits mais ou menos significativos.

OpenADC Descrição

Configura o conversor A/D.

Biblioteca

adc.h

Protótipo

void OpenADC(unsigned char  config, unsigned char  config2 , unsigned char  portconfig);

Argumentos Config:

É uma máscara de “bits” formada por operações AND com os valores de cada uma das categorias listadas abaixo:

Clock do conversor A/D: ADC_FOSC_2

FOSC / 2

ADC_FOSC_4

FOSC / 4

ADC_FOSC_8

FOSC / 8

ADC_FOSC_16

FOSC / 16

ADC_FOSC_32

FOSC / 32

ADC_FOSC_64

FOSC / 64

ADC_FOSC_RC

Oscilador RC Interno

55

Justificação do resultado A/D:

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

Tempo de aquisição:

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 máscara de “bits” formada por operações 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

Interrupção A/D:

ADC_INT_ON Interrupção A/D habilitada ADC_INT_OFF Interrupção A/D desabilitada

Configuração de voltagem do conversor A/D:

ADC_VREFPLUS_VDD

VREF+ = AVDD

ADC_VREFPLUS_EXT

VREF+ = external

ADC_VREFMINUS_VDD

VREF- = AVDD

ADC_VREFMINUS_EXT

VREF- = external

 portconfig

O “portconfig” é um valor de 0 a 15 que configura os primeiros 4 “bits” do registrador ADCON1, que são os bits de configuração do “port”. Observação

Essa função “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 referência, “port” e canal.

Exemplo

OpenADC( ADC_FOSC_32 & ADC_RIGHT_JUST & ADC_12_TAD, ADC_CH0 & ADC_INT_OFF, 15 );

57

No “software” embarcado para interfaceamento com LM 35, o conversor A/D foi configurado com as seguintes características:      

“Clock” do conversor: divisão da freqüência externa por 8; Formato do resultado: justificado a direita; Tempo de aquisição: 12 TAD; Canal utilizado: canal 0; Interrupção da conversão A/D: desligada; Tensão de referência: interna baseada nos valores de Vdd e Vss.

Para estabelecer essa configuração a função OpenADC deve ser utilizada com os seguintes parâmetros: 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 saída, já que os oito “leds” para apresentação do resultado estão conectados a esses pinos. Em seguida, “limpa” o PORTB através de atribuição do valor 0x00 (0 em decimal), a fim de garantir consistência na apresentação do resultado. Posteriormente, o pino RA0 é definido como uma entrada e o conversor A/D é configurado com os devidos parâmetros, utilizando o pino RA0 como entrada analógica. A partir desse momento, o programa fica em “loop” infinito realizando conversões e exibindo o resultado nos 8 “leds”. Inicialmente, espera-se 20 microsegundos, inicia-se o processo de conversão, em seguida é verificado se a conversão foi terminada, caso não tenha sido, o programa continua verificando essa condição até que seja verdadeira. Assim que a conversão for concluída, 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 seção descreve os aspectos teóricos necessários para o interfaceamento do microcontrolador com o “display” LCD. São feitas considerações teóricas sobre a utilização do LCD, sua inicialização e configuração. Além disso, são apresentadas as funções utilizadas pelo “software” e o fluxograma que caracteriza o mesmo.

4.4.2.1. CONSIDERAÇÕES TEÓRICAS Os módulos LCD são periféricos que tornam muita prático o processo de visualização de dados. Em geral, um módulo LCD é composto basicamente de um controlador de “display”, que é responsável por processar os comandos enviados para o mesmo e de um “display” de cristal liquido (LCD) para exibir os dados. Os “displays” alfanuméricos são mais baratos e mais adequados para apresentar caracteres como números, letras e símbolos, sendo sua tela dividida e organizada de forma matricial em linhas e colunas, onde cada posição 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 é compatível com o controlador HD 44780, considerado um padrão. Esses controladores permitem uma comunicação simples com sistemas microcontrolados, possuindo largura de barramento que pode ser de 4 ou 8 “bits”, além de um conjunto de três sinais de controle: ENABLE, R/W e RS. A comunicação 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 são transferidos, iniciando-se pelo mais significativo. O controlador do “display” deve receber comandos para realizar as diversas operações possíveis. Mas antes de enviar comandos para o mesmo, ele deve ser inicializado. Há todo um procedimento padrão que leva em consideração a temporização para poder realizar a inicialização. O fluxograma do processo de inicialização, que deve ser feito pelo “software” do usuário, pode ser visto na Figura 4.12.

60

Figura 4.12 - Procedimentos necessários para a inicialização do display LCD.

61

Após o processo de inicialização do “display”, o cursor irá para a posição 0x00 (primeira linha e primeira coluna). A cada dado (caractere) que é enviado para o “display”, o mesmo automaticamente desloca o cursor para a próxima posição, evitando dessa forma, que o usuário precisa posicionar o cursor na posição seguinte toda vez que deseja enviar um caractere. Mas, caso a intenção seja escrever em uma posição que não é imediatamente consecutiva, devese posicionar o cursor nessa posição manualmente. Para isso é necessário que os pinos RS e R/W estejam em nível alto e o “bit” mais significativo dos dados deve estar em nível alto. O endereçamento direto de um display de 16x2 pode ser visto na Figura 4.13.

Figura 4.13 - Endereçamento direto de um display LCD 16x2.

Como o “bit” mais significativo dos dados deve possuir valor “1” para se posicionar o cursor na posição desejada, deve-se adicionar o valor 0x80 aos endereços 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 endereçamento direto do “display” apresentado na Figura 4.13. O resultado dessa operação e o valor que deve ser enviado para o “display”, para que o mesmo posicione o cursor na posição correspondente, pode ser visto na Figura 4.14.

Figura 4.14 - Relação entre posição 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 posição para posicionamento do display pode ser visto na Figura 4.15.

Figura 4.15 - Relação entre posição e valor hexadecimal que deve ser enviado ao display LCD 20x4 para posicionamento manual de cursor. 62

4.4.2.2. CONSIDERAÇÕES DE IMPLEMENTAÇÃO A implementação do “software” embarcado foi feita na linguagem C (ANSI) e foram utilizadas as bibliotecas do compilador C18, que é o compilador específico da Microchip para os microcontroladores da família PIC 18. A seguir é feita uma breve descrição das principais funções utilizadas para comunicação com o Display LCD. As funções e respectivas considerações podem ser vistas na Tabela 4.4.

Tabela 4.4 - Descrição das principais funções do compilador C18 relacionadas à comunicação com display LCD.

BusyXLCD Descrição

Verifica se o controlador do display LCD está ocupado

Biblioteca

xlcd.h

Protótipo

unsigned char BusyXLCD( void );

Observações

Essa função retorna o “status” da “flag” de ocupado do controlador do LCD.

Valor de retorno

1, Se o controlador do LCD está ocupado; 0, Se o controlador não está ocupado.

OpenXLCD Descrição

Configura os pinos para comunicação com o display LCD e inicializa o mesmo.

Biblioteca

xlcd.h

Protótipo

void OpenXLCD( unsigned char lcdtype );

Argumentos

lcdtype

É uma máscara de “bits” formada por operações 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”

Configuração do LCD: LINE_5X7

5x7 caracteres, linha única do display

LINE_5X10 5x10 caracteres do display LINES_5X7 5x7 caracteres, múltiplas linhas do display Observação

Essa função configura os pinos de I/O dos microcontroladores da família PIC 18 para comunicarse com o controlador do display LCD. Essa função também responsável pelo processo de inicialização do display.

putcXLCD WriteDataXLCD Descrição

Envia um byte para o controlador do LCD.

Biblioteca

xlcd.h

Protótipo

void WriteDataXLCD( char data );

Argumentos

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

Observação

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

putsXLCD putrsXLCD Descrição

Envia uma string para o controlador do LCD.

Biblioteca

xlcd.h

Protótipo

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.

Observação

Essa função envia uma “string” de caracteres apontada por “buffer” para o controlador LCD. O processo de transmissão é finalizado quando um caractere nulo é encontrado, o mesmo não é transmitido. “Strings” localizadas na memória de dados devem utilizar a função putsXLCD. Já as “strings” localizadas na memória de programa, incluindo “strings” literais, devem utilizar a função putrsXLCD.

WriteCmdXLCD Descrição

Envia um comando para o controlador do LCD

Biblioteca

xlcd.h

Protótipo

void WriteCmdXLCD( unsigned char cmd );

Argumentos

 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

Ativa display com cursor piscante

BLINK_OFF

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 Observação

Essa função envia um comando para o controlador do LCD. O controlador não deve estar ocupado no momento do envia dos dados, para evitar esse problema a função BusyXLCD deve ser utilizada. 65

Além das funções acima, também devem ser utilizadas algumas funções para configuração da temporização do envio de dados para o “display” LCD. Essas funções são: DelayFor18TCY, DelayPORXLCD e DelayXLCD. As mesmas são utilizadas internamente pelas funções definas pelo compilador C18 para comunicação com o “display” LCD. A implementação dessas funções é de responsabilidade do usuário, 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 também é uma união dos “softwares” embarcados para interfaceamento com “display” e sensor LM 35. Logo as considerações teóricas e de implementação são as mesmas das descritas nas seções 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 ATRAVÉS DE UM SERVIDOR HTTP MICROCONTROLADO Essa seção descreve os aspectos teóricos e de implementação relacionados ao “software” para monitoramento de temperatura baseado em um servidor HTTP microcontrolado. São descritas, de forma breve, as principais tecnologias e recursos necessários para implementação do “software” embarcado e é apresentado o respectivo fluxograma.

4.4.4.1. CONSIDERAÇÕES TEÓRICAS Nas próximas seções são apresentadas as principais tecnologias utilizadas no desenvolvimento do “software” embarcado dessa seção.

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 consideração todas as especificações contidas nas RFCs de cada um dos protocolos que implementa, já que o objetivo da mesma é permitir a conexão de microcontroladores à Internet, de forma transparente, como se fosse um “host” qualquer, ou seja, o fato de ser um dispositivo microcontrolado e não um computador, por exemplo, não deveria ser percebido. Na Figura 4.18 pode ser vista uma representação da pilha TCP/IP da Microchip. Alguns dos serviços implementados atualmente pela mesma não estão apresentados nesta figura, principalmente os serviços da camada de aplicação. Assim como na especificação do modelo TCP/IP, a pilha TCP/IP da Microchip é dividida em diversas camadas, como pode ser visto na Figura 4.19. A implementação de cada uma das camadas é feita em arquivos separados, enquanto que os serviços e a API são definidas através de arquivos “header/include”. Diferentemente do modelo de referência TCP/IP, muitas camadas da pilha TCP/IP da Microchip acessam diretamente uma ou mais camadas que não estão necessariamente “abaixo” delas. A decisão de quando uma camada deve “bypassar” a adjacente é necessária, e foi feita preliminarmente, devido à quantidade de “overhead” e levando-se em conta se era necessário ou não fazer um processamento “pesado” antes de passar para a próxima camada.

69

Figura 4.18 - Organização da pilha TCP/IP da Microchip.

Figura 4.19 - Comparação entre a estrutura da pilha TCP/IP da Microchip e o modelo de referência TCP/IP.

A pilha TCP/IP da Microchip é chamada de pilha “viva”, pois algumas camadas devem estar aptas a executar algumas operações de forma assíncrona. Para permitir essa característica e também possibilitar uma relativa independência entre a aplicação principal e os serviços utilizados pela mesma, a pilha TCP/IP da Microchip utiliza uma técnica 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ó então a próxima tarefa fica apta a ser executada. Geralmente o cooperativismo multitarefa é implementado pelo sistema operacional ou pela própria aplicação principal. A pilha TCP/IP da Microchip foi desenvolvida para ser independente de qualquer sistema operacional e, por isso, ela implementa seu próprio mecanismo cooperativo multitarefa. Dessa forma, ela pode ser utilizada em qualquer sistema, independente se o mesmo utiliza o sistema cooperativo multitarefa ou não. De qualquer forma, uma aplicação que utiliza a pilha TCP/IP da Microchip deve também utilizar o método cooperativo multitarefa. Isso é feito através da divisão de um programa em múltiplas tarefas, ou organizando o programa principal como uma máquina de estados finita (FSM) e dividindo um programa grande em diversos programas pequenos.

70

A pilha TCP/IP da Microchip não implementa todos os módulos que estão presentes em uma pilha TCP/IP tradicional. Apesar de não estarem presentes, eles podem ser implementados como uma tarefa ou módulo separado, se necessário. A diferença 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 pressupõem a presença de um sistema operacional, que é o responsável pela gerência da mesma. No caso dos microcontroladores, a presença de um sistema operacional é um fator complicador,  já que os mesmos são dispositivos limitados, que trabalhavam apenas com 8 “bits” na época do desenvolvimento da pilha e possuíam poucas centenas de “bytes” de memória RAM e uma limitada memória 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 páginas WEB no microcontrolador. A imagem do sistema de arquivos MPFS pode ser armazenada na memória de programa do microcontrolador ou em uma memória externa serial do tipo EEPROM. O MPFS segue um formato especial para armazenar múltiplos 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 usuário assim desejar. Esse bloco reservado pode ser utilizado pela aplicação principal para armazenar dados de configuração. 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, localização 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 contém 16 ou 24 “bits” de endereçamento. O tamanho do endereçamento é determinado pelo tipo de memória utilizada, bem como o modelo de tamanho de memória (“large” ou “small”). Se a memória de programa interna do microcontrolador é utilizada e o projeto com a pilha TCP/IP da Microchip é compilado utilizando o modelo “small”, o endereçamento de 16 “bits” é utilizado. Se a memória de programa interna é utilizada e o modelo “large” é utilizado, o endereçamento utilizado é de 24 “bits”. Sempre que uma memória serial externa EEPROM é utilizada, o endereçamento de 16 “bits” é utilizado, independente do modelo de tamanho de memória utilizado. Isso implica em uma imagem do MPFS de no máximo 64 Kb para a memória externa. O MPFS utiliza nomes pequenos para os arquivos: 8 “bytes” para o nome dos arquivos e 3 “bytes” para a extensão, por exemplo: xxxxxxxx.zzz. Um endereço de 16 “bits” indica o início do primeiro arquivo do bloco de dados. Todos os nomes de arquivo são armazenados em letra maiúscula para facilitar o processo de comparação dos nomes. O campo de endereço em cada entrada FAT contém uma referência para um bloco de dados que contém os dados do arquivo em questão. 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 endereçamento de 16 “bits”) ou FFFFFF (para endereçamento de 24 “bits”). Se a parte de dados do bloco contém 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 aplicação para PC, que pode ser utilizada para construir uma imagem MPFS, para ser armazenada no microcontrolador ou em uma memória externa serial EEPROM, a partir de um conjunto de arquivos que em geral são páginas HTML, imagens, dentre outros. Dependendo de onde a imagem MPFS será armazenada, o usuário pode gerar um arquivo de dados em linguagem C ou um arquivo binário que represente a imagem MPFS. A sintaxe dos comandos para utilizar o MPFS “builder” pode ser visto a seguir:

mpfs [/?] [/c] [/b] [/r] < InputDir> Onde: /? Exibe um “help” na linha de comandos /c Gera um arquivo de dados em C /b Gera um arquivo binário (é a opção padrão) /r reserva um bloco de memória no inicio do arquivo (válido apenas se o arquivo gerado é binário, o tamanho padrão do bloco é 32 “bytes”) é o diretório que contém os arquivos com os quais se deseja criar a imagem é o nome do arquivo de saída

O Resultado do comando “mpfs /?” pode ser visto na Figura 4.23.

Figura 4.23 - Resultado do comando "mpfs /?" no utilitário MPFS.exe 73

Por exemplo, o comando: mpfs /c mypages.c gera uma imagem MPFS como um arquivo de dados, em linguagem C, chamado “mypages.c”, com o conteúdo do diretório “Your WebPage Dir”. Já o comando: mpfs mypages.bin, gera um arquivo binário que representa a imagem MPFS com 32 “bytes” de bloco reservado. O comando: mpfs /r128 mypages.bin , gera o mesmo arquivo que o anterior, mas como 128 “bytes” de bloco reservado. Antes de a imagem ser criada, o usuário deve criar todas as páginas WEB, “linká-las” e salvar em um único diretório. Se arquivos com a extensão “htm” são utilizados, o MPFS “Image Builder” retira todos os caracteres de “retorno de cursor” e tabulação, a fim de diminuir o tamanho da imagem gerada. Se a imagem MPFS for armazenada na memória interna do microcontrolador, o código C gerado deve ser “linkado” com o projeto que contém a pilha TCP/IP e o programa de aplicação do usuário. Se a imagem será armazenada em uma memória externa serial EEPROM, o arquivo binário deve ser gravado no “chip” de memória EEPROM. O MPFS “Image Builder” não verifica limitações de tamanho, ficando assim como responsabilidade do usuário verificar se a memória 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 necessárias para acessar o dispositivo (o próprio microcontrolador ou uma memória serial EEPROM externa), que está armazenando a imagem MPFS. O usuário não precisa entender os detalhes de baixo nível do MPFS, para poder usar recursos do servidor HTTP relacionados ao MPFS. Todos acessos ao MPFS são realizados internamente pelo servidor HTTP da pilha TCP/IP , sem a necessidade de intervenção da aplicação do usuário. A versão utilizada do MPFS “Access Library” não permite a adição ou deleção de arquivos individuais de uma imagem existente, ou seja, todos os arquivos fazem parte de uma única e indissociável imagem. Qualquer mudança necessária deve acarretar a geração de uma nova imagem com as novas características desejadas. Se a memória de programa interna do microcontrolador é utilizada para armazenar a imagem MPFS, a macro MPFS_USE_PGRM deve ser definida. Já se uma memória EEPROM externa é utilizada, a macro MPFS_USE_EEPROM deve ser definida. Apenas uma das duas definições pode ser utilizada: em tempo de compilação essa consistência é verificada. Dependendo do tipo de dispositivo de memória utilizado, o “buffer” de página pode variar. A configuração padrão do tamanho do “buffer” da página é 64 “bytes”, sendo a mesma definida pela macro MPFS_WRITE_PAGE_SIZE no arquivo “MPFS.h”. Se um tamanho de “buffer” diferente é desejado, o usuário deve alterar o valor da macro MPFS_WRITE_PAGE_SIZE. 74

4.4.4.1.3. MICROCHIP HTTP SERVER O servidor HTTP incluído na pilha TCP/IP da Microchip é implementando como uma tarefa cooperativa, que co-existe com a pilha TCP/IP e a aplicação do usuário. A implementação desse servidor é feita no arquivo “HTTP.c”, com a aplicação do usuário sendo responsável pela implementação de duas funções do tipo “callback”, ou seja, funções que são chamadas automaticamente pelo servidor HTTP e que devem executar alguma tarefa a ser definida pelo usuário. Esse servidor não implementa todas as funcionalidades HTTP típicas. Na verdade, o servidor HTTP é uma implementação mínima para sistemas embarcados, que leva em consideração as características e limitações dos mesmos. Mas, de acordo com a Microchip, o usuário pode realizar implementações de outras funcionalidades e/ou recursos definidos pela RFC do protocolo. Algumas funcionalidades do servidor HTTP podem ser vistas a seguir:

  

 



Suporte a múltiplas conexões HTTP; Dispõe de um sistema de arquivos próprio (MPFS); Suporta páginas WEB localizadas na memória de programa do microcontrolador ou em memória EEPROM serial externa; Suporta método de envio GET (outros métodos podem ser adicionados); Suporta um tipo de CGI (“Common Gateway Interface”) para executar funcionalidades pré-definidas a partir de um “browser” remoto; Suporta geração dinâmica de conteúdo de páginas WEB.

Para integrar o servidor HTTP em uma aplicação do usuário, os seguintes passos devem ser seguidos:





 



Descomentar o macro STACK_USE_HTTP_SERVER no arquivo de cabeçalho “StackTsk.h”, para habilitar o código do servidor HTTP; “Setar” a quantidade máxima de conexões que se deseja para o servidor HTTP na macro HTTP_MAX_CONNECTIONS no arquivo de cabeçalho “StackTsk.h”; Incluir os arquivos “http.c” e “mpfs.c” no projeto a ser compilado; Dependendo de onde as páginas WEB serão armazenadas, descomentar a macro MPFS_USE_PGRM ou MPFS_USE_EEPROM. Se uma memória externa EEPROM é utilizada para armazenamento de dados, o arquivo “xeeprom.c” também deve ser utilizado; Modificar a função “main” no programa de aplicação para incluir e inicializar os serviços do servidor HTTP.

O servidor HTTP usa o arquivo de nome “index.htm” como página WEB padrão. Se um “browser” remoto acessa o servidor HTTP pelo seu endereço IP ou domínio, a página de nome “index.htm” é enviada ao cliente. Dessa forma, é necessário que todas as aplicações que 75

utilizam o servidor HTTP tenham uma página de nome “index.htm” como integrante do conteúdo da imagem MPFS. Se o usuário julgar necessário, o nome da página padrão pode ser alterada, mudando o valor da macro HTTP_DEFAULT_FILE_STRING no arquivo “HTTP.c”. O servidor HTTP contém uma lista com os tipos de arquivo que o mesmo suporta. Ele usa essas informações para indicar ao “browser” cliente como interpretar um arquivo em particular, baseado nas três letras que compõem a extensão do arquivo. Por padrão, o servidor suporta as extensões “txt”, “htm”, “gif”, “cgi”, “jpg”, “cla” e “wav”. Se a aplicação necessitar utilizar algum arquivo com extensão que não seja nenhuma das anteriormente citadas, o usuário deve modificar a tabela “httpFiles” junto com a enumeração “httpContents” no arquivo “HTTP.c”.

4.4.4.1.3.1. GERAÇÃO DINÂMICA DE PÁGINA

O servidor HTTP pode alterar páginas dinamicamente e substituir informações em tempo-real que podem, por exemplo, se referir “status” das E/S do microcontrolador. Para incorporar essa capacidade de informações em tempo-real, um arquivo CGI (*.cgi) deve conter uma “string” no formato “%xx”, onde o caractere “%” é utilizado como código de controle e “xx” é um identificador de dois dígitos. 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 à função de “callback” HTTPGetVar. Se o usuário deseja exibir na página 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 informação “25%” deve ser apresentada na página, no código “htm” ou “cgi” deve ser colocado o valor “25%%”. As características da função HTTPGetVar são apresentadas a seguir:

76

HTTPGetVar É uma função de “callback” do servidor HTTP. Quando o servidor HTTP encontra uma “string” no formato “%xx” em uma página CGI que está sendo processada, o servidor executa essa função. A mesma deve ser implementada pela aplicação do usuário e utilizada para transferir dados de uma variável interna do microcontrolador para o HTTP.

Sintaxe: WORD HTTPGetVar (Byte var, WORD ref, Byte *val)

Parâmetros: 

var [entrada] Identificador da variável cujo valor deve ser retornado.



ref [entrada]

Referência da chamada. O valor dessa referência indica se chamada é a primeira, na instância corrente. Após a primeira chamada, esse valor deixa de ser pré-definido e passa a ser gerenciado pelo programa de aplicação do usuário. O servidor HTTP utiliza o valor de retorno dessa função, para determinar se a mesma deve ser chamada novamente para obter mais dados. Como apenas um “byte” é transferido por vez, o valor da referência é uma ferramenta que permite que a aplicação do usuário busque mais dados. Por exemplo, se o valor da variável que se deseja obter possui mais de um “byte”, a aplicação do usuário pode usar a referência como índice para obter o conteúdo de um “array” de dados (“bytes”) e retorná-lo. Cada vez que um “byte” é enviado, o valor atualizado (ou não) da referência é utilizada como retorno dessa função, logo se a informação que se deseja retornar é um “array”, o programa do usuário deve incrementar a referência, apontando assim, para a próxima posição do “array”. Quando a aplicação enviou o último “byte”, o programa de aplicação do usuário deve fazer com que essa função retorne o valor da macro “HTTP_END_OF_VAR” como retorno da função. O servidor HTTP continua fazendo chamadas a essa função, até que a mesma receba “HTTP_END_OF_VAR” como valor de retorno. Além da macro “HTTP_END_OF_VAR”, outra macro utilizada pela função é “HTTP_START_OF_VAR”, que é o primeiro valor passado pela variável de referência, indicando que essa foi a primeira chamada à função, em uma determinada instância. Logo, se a aplicação do usuário deseja retornar um “array” de bytes, essa macro deve ser utilizada, para que a implementação do usuário saiba o momento de inicializar o índice da referência e passe a indexar o “array” a cada nova chamada da função. 

val [saída] Um “byte” de dados que deve ser transferido.

77

Valores de retorno: Novos valores de referência podem ser retornados e os mesmos são controlados pela aplicação do usuário. Se o valor de retorno da função não é “HTTP_START_OF_VAR”, o servidor HTTP chamará a função de novo, passando o valor antigo da variável “ref” (referência). Se o valor “HTTP_END_OF_VAR” é retornado pela função, isso indica ao servidor HTTP que não há mais dados a serem transmitidos e o mesmo considera a transmissão finalizada, não realizando novas chamadas a essa função.

Observações: Embora essa função requisite o valor de uma variável do programa de aplicação do usuário gravado no microcontrolador, o programa de aplicação pode não retornar um valor propriamente dito. Essa variável pode, por exemplo, ser um “array” de “bytes” que pode ou não representar o valor de uma variável. A informação que essa função retorna é totalmente dependente da aplicação do usuário e da página WEB. Por exemplo, uma variável com identificador “50” (%50) pode representar um “frame” JPEG de 100 x 100 pixels. Nesse caso, a aplicação pode usar o valor de retorno como referência para indexar o frame JPEG e retornar um byte por vez. O servidor HTTP continuará chamando a função, até que receba “HTTP_END_OF_VAR” como valor de retorno dessa função. Essa função retorna um valor de 16 bits, logo apenas um dado de 64 Kbytes pode ser transferido como um único valor de variável. Se um dado possui tamanho maior, duas ou mais variáveis devem ser utilizadas para aumentar a capacidade de transferência desse “array” de dados.

Como a função HTTPGetVar é um pouco complexa, a seguir se apresenta um exemplo de utilização da mesma. Suponha que tenha sido criado uma página chamada “status.cgi” que está sendo enviada pelo servidor HTTP e o conteúdo da mesma é o seguinte:

78

Status dos leds

LED 5

%05

LED 4

%04

LED 3

%03

Durante o processamento dessa página, 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 usuário implementou a função HTTPGetVar da seguinte forma: WORD HTTPGetVar(BYTE var, WORD ref, BYTE *valor) {// Identificação da variável. Verifica se a informação desejada é sobre o LED5(%05) if ( var == 5 ) {

// retornará “1” se o pino RB5 estiver em nível alto, “0” caso contrário 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 variáveis, por exemplo, LED4(%04) e LED3(%03) }

79

Com a implementação da função HTTPGetVar anterior, a página “status.cgi” será atualizada dinamicamente e em tempo real com o valor lógico presente no pino RB5 do microcontrolador. Basicamente, assim que o servidor encontrar o valor “%05” na página “status.cgi”, o mesmo chamará a função HTTPGetVar passando o identificador “5” como parâmetro. No corpo da função, é verificado se o identificador é “5”, caso seja, o nível lógico do pino RB5 é verificado e o valor correspondente é atribuído à variável apontada por “val”. Em seguida, a função retorna a macro HTTP_END_OF_VAR, para indicar ao servidor que o dado foi completamente transmitido e que a função não deve ser mais chamada para essa instância. O valor da “%05” é substituído pelo valor apontando pela variável “val” e a página é enviada para o cliente.

4.4.4.1.4. COOPERATIVE MULTITASKING O conceito e/ou política de multitarefa (ANDERSON, 1999) foi introduzida pelos sistemas operacionais. Um sistema operacional é dito multitarefa se é capaz de dividir o uso da CPU entre várias tarefas de forma concorrente. O conceito de cooperativo é utilizado quando as próprias tarefas são responsáveis por fornecer o controle da CPU para as demais. Dessa forma, uma tarefa só pode ser iniciada assim que a precedente for concluída e explicitamente atribuir o controle da CPU para a mesma. Assim, em um sistema cooperativo multitarefa, várias tarefas cooperam para a realização de um determinado trabalho. Em sistemas multitarefa várias tarefas requisitam o uso da CPU, mas apenas uma tarefa pode utilizar a CPU por vez. Então, algum mecanismo de coordenação e organização deve ser utilizado, para garantir que cada tarefa tenha sua vez de execução na CPU. Na prática, cada tarefa utiliza a CPU por um intervalo de tempo curto, dando a sensação de que as tarefas estão 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 possível, sendo que esse tempo é determinado pelo ambiente e/ou aplicação. Dessa forma, não há um tempo de resposta específico para classificar um sistema como de tempo real ou não. Executar em tempo real não 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 três etapas são necessárias:

  

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 hipotético para atividades necessárias para realizar o monitoramento de temperatura.

Tarefa

Tempo

Ler o valor da temperatura

200ms

Formatar o valor da temperatura

200ms

Exibir o valor da temperatura

300ms

Se essas tarefas forem realizadas por um sistema que também é responsável por outras, como por exemplo, verificar o “status” de um botão de alarme, problemas podem acontecer. Se essas três tarefas são executadas seqüencialmente como um único e indivisível procedimento, significa que durante 700ms o sistema será incapaz de realizar qualquer outra tarefa e não agirá da maneira prevista se o botão 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 concorrência 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. Além disso, a capacidade de “multithreading” permitiria que um fluxo de execução fosse responsável pelas tarefas relacionadas à temperatura e outro fluxo verificasse, em “loop”, o “status” do botão. Infelizmente, os microcontroladores ainda não possuem capacidades para permitir a implementação desses recursos, que são típicos dos sistemas operacionais modernos. Por exemplo, se for utilizado um “loop” para verificar o “status” do botão, o microcontrolador ficará preso nesse trecho de código e nunca executará as tarefas relacionadas à temperatura. Utilizando o sistema cooperativo multitarefa é possível reorganizar as tarefas de forma a permitir sua execução satisfatória. Além disso, os microcontroladores possuem capacidade de implementar essa política, já que a mesma não demanda praticamente nenhum recurso de “hardware” adicional. Suponha que, ao invés de utilizar um único procedimento para executar seqüencialmente as três tarefas relacionadas à temperatura, seja utilizada uma máquina de estados. Além disso, a cada execução de uma das tarefas da Figura 4.24, o fluxo volta ao programa principal, que monitora o “status” do botão e depois retorna à máquina de estados, para realizar a próxima tarefa e assim sucessivamente. Como conseqüência, cada tarefa será executada de forma satisfatória e o “status” do botão poderá ser monitorado de forma mais adequada. No pior caso, ser verificado a cada 300 ms, ao invés de 700 ms como anteriormente. Esse é o mecanismo principal utilizado pela pilha TCP/IP da Microchip: um serviço complexo é divido em várias tarefas, que realizam sua execução em um tempo aceitável e atribuem o controle da CPU para a próxima tarefa e assim sucessivamente. O servidor HTTP, por exemplo, é uma máquina de estados de 21 estados.

81

Apesar de tudo, a política cooperativa multitarefa utilizando máquina 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 não seja suficiente ou não tenha atingido o desempenho desejado, uma possibilidade é utilizar os sistemas operacionais de tempo-real (RTOS) que são uma pequena parte de código armazenado no microcontrolador, que será responsável por controlar a alocação das tarefas, quando o microcontrolador está operando em modo multitarefa. O RTOS decide, por instância, qual a próxima tarefa a executar, como coordenar prioridades entre as tarefas e como trocar dados e mensagens entre as mesmas.

Figura 4.24 – Tarefas necessárias 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 usuário, utilizando-se para isso de requisições assíncronas e outras tecnologias como HTML, CSS (Cascading Style Sheets) e DOM (Document Object Model). Na prática, significa que é possível fazer uma requisição ao servidor, sem que seja necessário recarregar a página que está sendo acessada no momento. O modelo clássico de visualização de conteúdos na WEB é baseado na requisição HTTP a partir do “browser” do cliente e na resposta do servidor através de uma nova página HTML. Esse modelo pode ser visto na Figura 4.25 (NIEDERAUER, 2007). Quando esse modelo é utilizado, a cada novo dado solicitado, toda a página com “layout” e imagens é recarregada, mesmo que a intenção seja exibir apenas um número, como o total de uma compra.

Figura 4.25 - Modelo clássico de visualização de conteúdos na WEB. 82

O modelo que o AJAX propõe pode ser visto na Figura 4.26 (NIEDERAUER, 2007). É interessante notar que a comunicação entre o navegador e o servidor WEB não ocorre diretamente, mas por meio da ferramenta AJAX. Como o AJAX é ativado por uma chamada “javascript”, o usuário pode continuar visualizando a página, enquanto ocorre a comunicação com o servidor WEB. O servidor WEB processa a solicitação AJAX, que pode ser uma pesquisa ou uma manipulação no banco de dados e envia uma resposta. Se o servidor responder com dados, o AJAX poderá utilizar esses dados para fazer a atualização de apenas uma parte da página que o usuário está visualizando, sem que seja necessário recarregá-la totalmente. Caso contrário, o usuário poderá continuar interagindo com a página, mas a mesma não sofrerá qualquer modificação visual.

Figura 4.26 - Modelo AJAX para visualização de conteúdo na WEB.

O uso do AJAX é muito comum em validação de formulários, atualização de enquetes, “chats on-line” via WEB, entre outras aplicações que priorizam a comunicação em tempo real. O principal objetivo do AJAX é melhorar a interatividade do usuário com o servidor, evitando interromper a interação do usuário com a página toda vez que a aplicação necessitar de informações do servidor. Devido essas características, além do AJAX ser atrativo visualmente, o mesmo economiza em recursos de banda já que a transmissão de dados é bem menor, uma vez que as páginas não são recarregadas a cada nova requisição e são páginas que ainda possibilitam a obtenção de informações em tempo real. A seguir são mostradas figuras (NIEDERAUER, 2007) que possibilitam a comparação em termos de desempenho e uso de recursos de uma aplicação WEB clássica e uma aplicação com AJAX.

83

Figura 4.27 - Fluxo de dados ao longo do tempo em uma aplicação WEB clássica.

Figura 4.28 - Fluxo de dados ao longo do tempo em uma aplicação WEB com AJAX.

Figura 4.29 - Gráfico comparativo dos dados transferidos ao longo do tempo entre uma aplicação WEB clássica e outra com AJAX.

84

4.4.4.2. FLUXOGRAMA A Figura 4.30 exibe o fluxograma apenas do programa de aplicação do “software” embarcado para monitoramento de temperatura e disponibilização dos dados a partir de um servidor HTTP microcontrolado. Mesmo exibindo apenas informações sobre o “software” de aplicação, ainda assim alguns recursos foram abstraídos a fim de evitar que o fluxograma ficasse demasiadamente extenso e complexo. Para o desenvolvimento deste “software” embarcado foi utilizada a versão 3.75 da Microchip TCP/IP Stack. Essa versão, apesar de antiga (última atualização em 02/08/2006), é a mais utilizada e a mais fiel à documentação técnica da Microchip. Além disso, a mesma já possui um grande conjunto de funcionalidades e necessita de poucos recursos do microcontrolador, diferente das versões mais atuais. Inicialmente, é feita a inicialização do “hardware”, que consiste na definição do pino RB7 como saída, do pino RA0 como entrada analógica e habilitação das interrupções, que são utilizadas internamente pela pilha TCP/IP. Em seguida, o conversor A/D é inicializado, assim como o “display” LCD e são enviadas informações para serem exibidas no “display” como endereço IP e MAC do circuito. Posteriormente, o temporizador é inicializado, sendo utilizado para garantir os prazos das tarefas e coordenar a utilização interna dos recursos da pilha TCP/IP. Em seguida, o sistema de arquivos MPFS e as camadas base da pilha TCP/IP são inicializadas. Logo em seguida, o servidor HTTP é inicializado. Depois dos processos de inicialização 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 implementação da aplicação é feita utilizando a política cooperativa multitarefa, é possível garantir que em uma operação normal tanto do circuito quanto da pilha TCP/IP, o “led” piscará a cada segundo. Através da observação do piscar desse “led” é possível ter uma noção 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, são de responsabilidade da pilha TCP/IP, bastando apenas que o usuário, a cada interação do “loop”, realize uma chamada das mesmas, para que suas máquinas 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 variável global, que armazena a temperatura atual, para que a mesma esteja acessível ao servidor HTTP. Quando a função de “callback” “HTTPGetVar” (implementada pelo usuário) é chamada pelo servidor HTTP, a mesma utiliza o valor de temperatura processado anteriormente, para montar a página HTML de resposta ao “browser” do cliente. A página HTML gerada utiliza AJAX para apresentar a temperatura. Dessa forma, novos valores de temperatura são carregados automaticamente e em tempo real. Caso o AJAX não fosse utilizado, o usuário teria que recarregar novamente a página (fazendo uma nova requisição 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 requisição 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 são intercambiáveis e garantem um bom desempenho. Mas, em uma fase posterior de otimização, essas considerações 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 disponibilização dos dados utilizando um servidor HTTP microcontrolado. 87

4.4.5. “SOFTWARE” EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVÉS DE UM CLIENTE TCP MICROCONTROLADO Essa seção descreve os aspectos teóricos e de implementação relacionados ao “software” para monitoramento de temperatura baseado em um cliente TCP microcontrolado.

4.4.5.1. CONSIDERAÇÕES TEÓRICAS As principais considerações teóricas para essa aplicação foram vistas nas seções 4.4.4.1.1 (Microchip TCP/IP “Stack”) e 4.4.4.1.3 (“Cooperative Multitasking”). Além disso, o cliente TCP microcontrolado utiliza “Berkelay Sockets” (MATTHEW; STONES, 2007) de rede para estabelecer comunicação 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 conexão na porta 12000. Dessa forma, o cliente TCP se conecta periodicamente ao mesmo e envia um número inteiro, que representa a temperatura atual monitorada pelo circuito. Para o desenvolvimento deste “software” embarcado foi utilizada a versão 4.55 da Microchip TCP/IP Stack. Essa versão era mais recente (última atualização em 11/10/2008) no momento da implementação deste “software”. Essa versão foi utilizada devido a 3.75 não possuir suporte a “Berkely Sockets”. Então, utilizou-se a versão 4.55 que possuía esse suporte e era mais atual na época da implementação (Fevereiro de 2009). O cliente TCP foi implementado utilizando a política cooperativa multitarefa. Sendo composto por quatro tarefas, que são organizadas conforme a máquina de estados descrita na Figura 4.31. A cada execução dessa máquina de estados, uma tarefa é realizada, independente do sucesso na execução ou não, o programa volta ao fluxo de execução do “loop” principal. Logo, a cada interação do “loop” principal, a máquina de estados do cliente TCP é executada. Caso uma determinada tarefa não tenha obtido êxito em sua execução, o próximo estado da máquina é mantido como o atual, para que em próximas execuções a tarefa desse estado possa ser realizada com sucesso. Uma das tarefas da máquina de estados do cliente TCP é exatamente a conexão ao “host” remoto. O estabelecimento dessa conexão dificilmente é concretizado nas primeiras tentativas, logo é justificável a organização do cliente TCP como uma máquina de estados, pois mesmo no caso de falha na tentativa de conexão, as tarefas realizadas pelos estados anteriores não são perdidas. O diagrama UML (UML, 2009) de transição de estados que descreve a máquina de estados utilizada pelo cliente TCP, implementada através de multitarefa cooperativa pode ser visto na Figura 4.31.

88

Figura 4.31 – Diagrama UML de transição de estados do cliente TCP microcontrolado.

4.4.5.2. FLUXOGRAMA Grande parte das etapas e/ou tarefas do cliente TCP são as mesmas do servidor HTTP microcontrolado. O processo de inicialização do circuito, a configuração do conversor A/D, a inicialização do “display” LCD e envio de dados, a inicialização do temporizador e do sistema de arquivos, são idênticos. Quando o fluxo de controle de execução chega na inicialização da pilha TCP/IP, o processo muda um pouco já que alguns serviços da pilha TCP/IP não são inicializados, por exemplo , o servidor HTTP. Na verdade, nem um serviço nativo da camada de aplicação 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 nível lógico do “led”, ou seja, piscá-lo. Posteriormente, realiza o processamento da temperatura e executa a máquina de estados do cliente TCP, passando a temperatura atual como parâmetro 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 disponibilização dos dados através de um cliente TCP microcontrolado. 90

4.4.6. “SOFTWARE” EMBARCADO PARA MONITORAMENTO DE TEMPERATURA ATRAVÉS DE CLIENTE TCP E SERVIDOR HTTP MICROCONTROLADOS Essa seção descreve apenas o fluxograma do “software” embarcado para monitoramente de temperatura através de cliente TCP e servidor HTTP microcontrolados. Esse “software” é híbrido e utiliza as duas formas para disponibilização dos dados de temperatura vistas anteriormente. Como este “software” é basicamente uma união dos dois programas embarcados desenvolvidos e comentados anteriormente, as considerações teóricas e de implementação são basicamente as mesmas vistas nas seções 4.4.4 e 4.4.5. Dessa forma, apenas o fluxograma que descreve a aplicação é apresentado e comentado.

4.2.6.1. FLUXOGRAMA Esse “software” híbrido basicamente possui todas as tarefas e funcionalidades do servidor HTTP e Cliente TCP microcontrolados em um único “software”. Como conseqüência, há muito código em comum aos dois “softwares”. Todo o processo desde o início da aplicação até a fase de processamento de temperatura é idêntico. No “software” do servidor HTTP microcontrolado, depois de processar a temperatura, o fluxo de execução voltaria para o início do “loop”. Neste “software”, antes disso, a máquina 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 versão 4.55 da Microchip TCP/IP Stack, já que a 3.75 não possui suporte a “Berkeley Sockets”. Mas como esse “software” é híbrido, ele utiliza a versão 4.55 para o cliente TCP e alguns recursos da versão 3.75 para o servidor HTTP. As versões mais novas da pilha TCP/IP ainda dispõem de códigos “legados”, dessa forma, não foi um problema sério realizar essa integração. Não foi utilizado o servidor HTTP da versão 4.55 por receio de que o mesmo necessitasse de mais recursos de memória de programa e desempenho. Mas essa questão pode ser verificada em fases futuras de otimização. Basicamente, esse “software” une as funcionalidades dos dois anteriores. Ou seja, ele é capaz de informar a temperatura a partir de uma página WEB, utilizando-se para isso de um servidor HTTP microcontrolado e, também é 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 genérica, que vai depender da necessidade e aplicação específica do usuário.

91

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

5. “DAEMON” PARA MONITORAMENTO REMOTO DE TEMPERATURA Neste capítulo são apresentadas informações relativas ao desenvolvimento do “software” para monitoramento remoto de temperatura. Esse programa é utilizando quando o “hardware” microcontrolado apresentado no Capítulo 4 é utilizado com o “software” embarcado cliente TCP. O “software” apresentado neste capítulo é responsável por realizar a conexão via rede com o “hardware” microcontrolado, obter os dados de temperatura e realizar um conjunto de atividades relacionadas, que incluem: monitoramento, armazenamento e notificação de alarme. Na seção sobre considerações teóricas, inicialmente é apresentado o conceito de “daemon”, posteriormente são feitas breves considerações sobre programação concorrente, processos, “threads”, comunicação interprocessos e o conceito de exclusão mútua. Em seguida, é apresentada a metodologia utilizada para o desenvolvimento do “software”, que inclui as ferramentas e recursos utilizados. A especificação formal do “software” é apresentada através dos seguintes diagramas UML 2.0 (UML, 2009): diagrama de casos de uso, diagrama de classes, diagrama de transição de estados e diagrama de atividades. Por último, são feitas considerações sobre a implementação, focando nos problemas encontrados, soluções adotadas e perspectivas.

5.1. CONSIDERAÇÕES TEÓRICAS Essa seção apresenta as considerações teóricas relacionadas ao “software” desenvolvido para fazer aquisição 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 não é controlado ativamente pelo usuário. Ou seja, o programa executa como um serviço e toma decisões automaticamente, não necessitando de comandos do usuário para cumprir sua tarefa. Muitos sistemas operacionais iniciam “daemons” durante o processo de inicialização. Esses “daemons”, em geral, têm propósitos de responder a atividades de rede, eventos de “hardware” ou a outros programas. Existem convenções para os nomes de “daemons”, o servidor HTTP Apache, por exemplo, é chamado de “httpd”. Mas essa nomenclatura é uma mera convenção, pois o “daemon” principal da aplicação “sendmail”, por exemplo, é chamado de “sendmail” e não de “maild”, como se poderia supor. Em alguns casos, os “daemons” precisam comunicar-se entre si. Essa comunicação em geral é feita através de um recurso chamado sinal. Através do mesmo é possível comunicar-se com um “daemon” ou qualquer outro programa em execução. Diversos sinais podem ser enviados, alguns com significado específico e outros cujo significado vai depender da aplicação. 93

5.1.2. UM POUCO SOBRE PROGRAMAÇÃO CONCORRENTE De uma forma geral, concorrência em computação 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 memória, os mesmos dispositivos de entrada/saída, dentre outros. Programação concorrente é o estudo da execução alternada (concorrente) de instruções atômicas de processos seqüenciais (SEIXAS FILHO; SZUSTER, 2002) . Instruções atômicas são instruções que o processador executa como operações indivisíveis, ou seja, a execução das mesmas não pode ser interrompida para realizar a execução de instruções de outro processo ou rotina de interrupção. Inclusive, são as ocorrências de interrupções no meio de uma operação que causam os maiores problemas em programação concorrente. A programação concorrente é muito mais difícil que a programação seqüencial (SEIXAS FILHO; SZUSTER, 2002) . Em geral, os programas concorrentes são mais difíceis de serem modelados, escritos, depurados e atualizados. Em programação concorrente, não basta apenas que os programas seqüenciais utilizados estejam logicamente corretos, também é necessário que o resultado produzido seja consistente e correto para qualquer alternância (intercalação) nas instruções com qualquer programa em execução, incluindo o sistema operacional. Em geral, os processos são escritos como programas seqüenciais e a ordem de execução das instruções deve ser preservada. Nos sistemas operacionais há um processo especial chamado de escalonador, que é o responsável por gerenciar e organizar a execução dos diversos processos que desejam ser executados na CPU. A técnica de dividir um problema em diversas tarefas (ou processos) que são executadas de forma concorrente é chamada de multiprogramação (“multitasking”). Além disso, um sistema produzido a partir desse paradigma é chamado de multitarefas ( TANENBAUM, 2007) .

5.1.3. PROCESSOS Um processo é basicamente a abstração de um programa em execução (TANENBAUM, 2007). Atualmente, os sistemas operacionais são capazes de realizar várias tarefas de forma concorrente: enviar um pacote pela rede, ler um arquivo armazenado no HD, enviar informações para placa de vídeo, dentre outros. Em um sistema multitarefa, o escalonador é o responsável por executar e gerenciar o chaveamento entre os vários processos, com relação ao uso da CPU durante um intervalo de tempo da ordem de milissegundos. Em geral, esse chaveamento é tão rápido que em apenas um segundo vários programas têm sua chance de usar a CPU para sua execução, dando a impressão de que foram executados em paralelo.

94

Figura 5.1 - Processos em um ambiente multiprogramado.

Na Figura 5.1(a) é possível ver um sistema “multitasking” (multitarefa) com quatro programas na memória principal. Na Figura 5.1(b) os quatro programas estão em execução sendo caracterizados dessa forma como processos, onde cada um tem seu próprio fluxo de execução, contador de programa lógico e é executado independentemente dos demais. Há somente um contador de programa físico, então quando um processo é colocado em execução, o seu contador de programa lógico é carregado no contador de programa real para a utilização. Na Figura 5.1(c), percebe-se que cada processo possui intervalos de tempo dedicados à sua execução e durante um intervalo de tempo apenas um processo pode ser executado. Um processo consiste basicamente do programa executável e informações relacionadas: dados, pilha, contador de programa, outros registradores e qualquer informação que seja necessária para sua execução ( TANENBAUM, 2007). Por exemplo, em um sistema operacional de tempo compartilhado, vários processos compartilham uma mesma CPU e, periodicamente, o sistema operacional decide suspender a execução de um processo e iniciar a execução 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 execução se inicie exatamente no trecho em que o mesmo foi suspendido anteriormente. Logo, toda informação do processo deve ser salva em uma estrutura de dados geralmente chamada de tabela de processos. Além disso, como não é possível estarem na memória principal do computador ao mesmo tempo todos os processos passíveis de execução, são necessárias operações de criação e destruição dinâmica de processos. Os possíveis estados de um processo no sistema operacional Linux podem ser vistos na Figura 5.2 (LINUXTUTORIAL, 2009).

Figura 5.2 - Possíveis estados de um processo no Linux. 95

5.1.4.”THREADS” Geralmente cada processo possui um único “thread” (fluxo) de controle (ou execução) e um espaço de endereçamento associado. Mas, algumas aplicações necessitam de múltiplos fluxos (“threads”) de execução em um mesmo espaço de endereçamento e executando em alto nível de concorrência, quase em paralelo, como se fossem processos independentes, exceto pelo fato de possuírem o mesmo espaço de endereçamento compartilhado. O modelo de processo visto na seção 5.1.3. é baseado em dois conceitos: agrupamento de recursos e execução. O que o modelo de “thread” propõe é exatamente a separação desses conceitos. Apesar de um “thread” ser associado e ter de executar em um processo, o “thread” e seu processo são conceitos diferentes e podem ser utilizados e tratados separadamente. Geralmente, os processos são utilizados para agrupar recursos, já os “threads” são as entidades escalonadas para execução na CPU. A característica principal acrescentada pelo “thread” ao modelo de processo é capacidade de um processo possuir, através dos “threads”, múltiplos fluxos de execução no mesmo ambiente do processo, com um grau elevado de independência entre os fluxos (TANENBAUM, 2007). Ter múltiplos “threads” executando concorrentemente em um processo é semanticamente análogo a múltiplos processos executando concorrentemente em um computador. Sendo que no primeiro caso, os “threads” compartilham o mesmo espaço de endereçamento, o que na prática significa o compartilhamento de arquivos abertos e outros recursos. Já os processos compartilham o espaço físico da memória e demais recursos de “hardware”. Como os “threads” possuem algumas propriedades em comum com os processos, também podem ser chamados de “processos leves”. O termo “multithread” significa a existência de múltiplos “threads” no mesmo processo. Na Figura 5.3 podem ser vistas duas formas de se criar três fluxos de execução: a) utilizando três processos cada um com seu “thread”; b) utilizando três “threads” de um único processo. Na Figura 5.3(a) existem três processos cada um com seu espaço de endereçamento e fluxo (“thread”) de execução. Já na Figura 4.3(b) existe um único processo, ou seja, um único espaço de endereçamento e três fluxos de execução. Logo, a diferença entre as duas situações é basicamente que, na Figura 5.3(b) os fluxos de execução compartilham o mesmo espaço de endereçamento e na Figura 5.3(a) não, cada fluxo possui seu próprio espaço de endereçamento.

Figura 5.3 - Duas formas de se criar três fluxos de execução usando processos e “threads”. 96

Quando um processo com múltiplos “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 multiprogramação, onde a CPU é alternada entre vários processos puramente seqüenciais, dando a ilusão de que são executados em paralelo, o “multithread” possui semântica similar. Mas, nesse caso, a CPU não alterna entre processos e sim entre “threads”, dando a impressão que os “threads” estão sendo executados em paralelo. “Threads” distintos em um mesmo processo não são tão independentes quanto processos distintos. Pois todos os “threads” compartilham o mesmo espaço de endereçamento. Na prática, significa que eles compartilham as mesmas variáveis globais e os mesmos recursos, como: arquivos abertos, sinais, processos filhos, alarmes, dentre outros. Então se um “thread” abre um arquivo, o mesmo também fica disponível para os demais “threads” desse processo. Esse fato faz muito sentido, já que a unidade de gerência de recursos é o processo e não o “thread”. Logo, todos recursos do processo vão estar disponíveis para os “threads” do mesmo. Além disso, se um “thread” possuísse seu próprio espaço de endereçamento, arquivos abertos, alarmes, dentre outros, ele seria de fato um processo e não apenas um “thread”. A idéia principal do “thread” é compartilhar recursos para múltiplos fluxos de execução, de tal forma a permitir que esses fluxos tenham acesso ao recurso e possam cooperar na realização de uma determinada tarefa ( TANENBAUM, 2007). Os possíveis estados de um “thread” no sistema operacional Linux podem ser vistos na Figura 5.4 (HEIDRICH, 2009).

Figura 5.4 - Possíveis estados de um "thread" no Linux.

Apesar de os “threads” introduzirem possibilidades interessantes de processamento concorrente, eles também introduzem diversas complicações para o modelo de programação. Por exemplo, supondo que um dos cinco “threads” de um processo esteja em execução e o mesmo identifique que há pouca memória disponível e comece a alocar mais memória. No meio dessa tarefa, a CPU intercala entre os demais quatro “threads”, onde os mesmos constatam o mesmo fato em relação à memória. Conseqüência: a memória 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 comunicação interprocessos e sincronização.

5.1.5. PROCESSOS X “THREADS” O principal fator motivador para a existência dos “threads” consiste no fato de que em muitas aplicações ocorrem múltiplas atividades de forma concorrente. Então, a possibilidade de dividir uma aplicação em múltiplos “threads”, onde cada um deles é responsável pela execução de uma atividade, é realmente interessante e importante. Além disso, os “threads” compartilham entre si o mesmo espaço de endereçamento, recursos e dados. Isso é fundamental, pois em algumas aplicações, múltiplos processos (espaço de endereçamento separado) não funcionariam adequadamente. Os “threads” são mais fáceis de criar e destruir que os processos, pois tem poucos recursos associados. Mais precisamente: possuem apenas os recursos necessários exclusivamente para que existam como código executável (BARNEY, 2009). Em muitos sistemas criar “threads” é cem vezes mais rápido do que criar um processo ( TANENBAUM, 2007). Essa propriedade é muito importante, quando uma aplicação necessita criar e destruir “threads” dinamicamente e em um intervalo de tempo curto. Na Figura 5.5 pode ser observada uma comparação na criação de “threads” e processos, utilizando recursos de um sistema operacional baseado em Unix (BARNEY, 2009). Nesse teste, foi realizada a criação de 50.000 “threads” e processos. Para criação de “threads” foi utilizada a função “pthread_create” da biblioteca “Pthread” e para criação de processos foi utilizada a chamada de sistema “fork”. Para análise do parâmetro 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 execução, em segundos, de um programa baseado em três parâmetros: real – tempo total utilizado pela aplicação, desde sua execução até a finalização; user – o tempo de CPU gasto pelo processo; sys – o tempo gasto pelo sistema para preparar em “kernel mode” a execução do programa: carregar, mover o código e iniciar a execução.

Figura 5.5 - Comparação em termos de tempo para criação de "threads" e processos.

De acordo com (TANENBAUM, 2007), o uso de “threads” não resulta necessariamente em ganho de desempenho, quando todos eles são orientados a CPU. Mas quando há um grande 98

número de processamento (computação) e de operações de entrada/saída, o uso de “thread” aumenta o desempenho da aplicação, já que essas atividades serão sobrepostas: enquanto uma parte delas está operando entrada/saída, as outras estão executando operações na CPU.

5.1.6. COMUNICAÇÃO 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 comunicação entre processos existe e deve ser feita de uma maneira estruturada e sem interrupções para evitar inconsistências. As informações apresentadas nessa seção também valem para “threads”. Dois dos principais assuntos abordados pela comunicação interprocessos são as condições de disputa e regiões críticas. As definições desses dois termos podem ser observadas a seguir: 



Condições de disputa: situações nas quais dois ou mais processos estão lendo e/ou escrevendo algum dado em uma memória compartilhada, cujo resultado final depende das informações de qual processo efetuou operações e quando executou precisamente. Regiões críticas: parte do programa onde há manipulações de uma memória compartilhada.

5.1.6.1. EXCLUSÃO MÚTUA Dois ou mais processos que operam de forma concorrente sobre uma região crítica estão sujeitos a condições de disputa. O ideal para resolver o problema seria o acesso à região critica ser realizado por instruções atômicas, mas essa solução é de difícil implementação. É possível desenvolver programas que operam de forma concorrente e intercalada sobre uma região não crítica e quando operam em uma região crítica tem suas instruções executadas de forma indivisível, como se fossem uma única instrução atômica. Se um determinado programa com processos concorrentes garante que apenas um processo está executando em uma determinada região crítica, se diz que o mesmo está operando garantindo exclusão mútua. Região crítica também pode ser definida como um trecho de um programa que deve ser executado sob exclusão mútua, e região crítica é o trecho do programa que, por definição, é executado sob exclusão mútua (SEIXAS FILHO; SZUSTER, 2002). Em programação concorrente deve-se modelar e definir uma forma organizada para entrar e sair da região crítica, de forma que apenas um processo possa entrar na mesma por vez e, assim que sair, avisar os demais que a região crítica está novamente liberada para o acesso. De certa forma, o que está sendo feito é apenas serializar o acesso à região crítica. Caso um 99

processo tente acessar a região crítica enquanto outro está executando, o primeiro deve ficar esperando até que a mesma seja liberada. Basicamente quatro condições devem ser satisfeitas para se operar de forma correta, consistente e satisfatória sobre uma região crítica:









Nunca dois processos podem estar simultaneamente em uma mesma região crítica; Se apenas um processo deseja entrar em sua região crítica, ele deverá fazer com o mínimo de “overhead”; Nenhum processo executando fora de sua região crítica pode bloquear outros processos; Nenhum processo deve esperar eternamente para entrar em sua região crítica.

Os principais mecanismos de programação concorrente para coordenar o acesso a regiões críticas e possibilitar comunicação interprocessos são:







Semáforo: é uma variável especial que tem como objetivo permitir o acesso a regiões críticas em ambientes multiprogramados. São efetuadas duas operações padrões nos semáforos: “Wait” ou P – decrementa o valor do semáforo. Se o semáforo possui valor zero, o processo é colocado para dormir; “Signal” ou V – se o semáforo possui valor zero e existir algum processo dormindo, um processo será acordado. Caso contrário, o valor do semáforo é incrementado. O valor inicial de um semáforo indica quantos processos podem ter acesso à região crítica. Mutex: é uma variável especial que pode estar em apenas dois estados: travado ou liberado. Assim como os semáforos, os mutexes são adequados para gerenciar o acesso a recursos compartilhados garantindo exclusão mútua. Os mutexes podem, inclusive, ser implementados com semáforos binários, ou seja, semáforos que podem apenas assumir dois valores 0 ou 1 e que, conseqüentemente, permitem acesso de um único processo à região crítica. São permitidas duas operações nos mutexes: “lock” e “unlock”. Quando um processo deseja acessar sua região crítica ele executa um “lock”. Dessa forma, qualquer outro processo que tentar entrar na região crítica nesse momento será automaticamente bloqueado e permanecerá nesse estado, até que o processo na região crítica termine e chame a operação “unlock”, liberando assim a região crítica para acesso. Monitor: é uma unidade básica de sincronização de alto nível. Um monitor é uma coleção de procedimentos, variáveis e estrutura de dados, agrupadas em um tipo especial de módulo ou pacote. Os processos podem executar procedimentos do monitor quando quiserem, mas não podem acessar diretamente, a partir de procedimentos declarados externos ao monitor, as suas estruturas internas de baixo nível. Os monitores apresentam uma característica importante para garantir exclusão mútua: somente um único processo pode estar ativo no monitor em um dado momento. Os monitores são construções de 100

linguagem de programação e, portanto, os compiladores ou interpretadores sabem que eles são 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 execução no monitor. Basicamente, com um modelo de concorrência baseado em monitores, os mecanismos de tratamento de exclusão mútua são transparentes para o programador, ou seja, o mesmo não é mais responsável pelo gerenciamento (bloqueio e desbloqueio) manual da região crítica, como no caso do semáforo e Mutex. 

Troca de mensagens: esse método de comunicação interprocessos utiliza duas operações, “send” e “receive”, que assim como os semáforos e diferente dos monitores, são chamadas de sistema e não recursos de uma determinada linguagem de programação. A operação “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 comunicação entre processos de uma mesma máquina ou em máquinas distintas que estão conectadas via rede. Em alguns sistemas operacionais, a troca de mensagens é transparente, independentemente se os processos estão sendo executados em uma mesma máquina ou em máquinas distintas conectadas por uma rede.

5.2. METODOLOGIA O “software” para aquisição 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 estão relacionados a recursos de baixo nível 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 são basicamente classes C++ que estendem a classe “thread” desenvolvida. Os “theads” e mutex utilizados são definidos pelo padrão IEEE POSIX 1003.1c também conhecidas como POSIX Threads ou PThreads (YOLINUX, 2009). Já os sinais (“signal”) utilizados são os padrões disponíveis nos sistemas derivados do Unix, como o Linux. Para o mecanismo de comunicação remota foram utilizados os “Berkeley sockets” de rede. Além disso, a API em linguagem C do MySQL (MYSQL, 2009) foi utilizado pelo “software” de monitoramento para fazer inserções e recuperações de dados armazenados no banco de dados. Na próxima seção são apresentadas algumas ferramentas utilizadas para o desenvolvimento do “software” de monitoramento e também alguns recursos utilizados pelo mesmo.

101

5.2.1. ECLIPSE IDE CDT Eclipse IDE (ECLIPSE, 2009) é um IDE (Ambiente de desenvolvimento integrado) de código 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 versão do Eclipse IDE para o desenvolvimento em C/C++. O Eclipse CDT dispõe dos seguintes recursos: suporte para criação e gerenciamento de projetos, utilitário “make” incluso, editor de código, hierarquia de código, grafo de chamadas, sintaxe “highlighting”, ferramentas de busca, auto-completar, refatoramento e geração de código, integração com diversos compiladores C/C++, depuração visual com a possibilidade de visualizar registradores, memória 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 características do MySQL são: • • • • • •

• • • • • • • • •

Portabilidade (suporte a grande maioria dos sistemas operacionais modernos); Compatibilidade (existem diversos “drivers” e APIs para comunicação com diversas linguagem de programação); Excelente desempenho e estabilidade; Baixa exigência de recursos de “hardware”; Tabelas “hash” em memória que são usadas como tabelas temporárias; Um sistema de privilégios e senhas que é muito flexível, seguro e que permite verificação baseada em estações/máquinas. As senhas são seguras porque todo o tráfego de senhas é criptografado durante a conexão ao servidor; Suporte total a “multithread”, usando “threads” diretamente no “kernel”; Facilidade de uso; É um Software Livre com base na licença GPL (General Public License); Permite a utilização de vários “Storage Engines” como MyISAM, InnoDB, Falcon, BDB, CSV, dentre outros; Suporta controle transacional; Suporta “Triggers”; Suporta “Stored Procedures” e “Functions”; Replicação facilmente configurável; Possui diversas ferramentas para gerenciamento através de interface gráfica.

Figura 5.8 - Logo do SGBD MySQL.

5.2.3. “POSIX THREADS” É um padrão POSIX (Portable Operating System Interface) para “threads”, que define uma API padrão para criação e manipulação de “threads”. As bibliotecas que implementam as “threads” POSIX são chamadas “Pthreads”, são muito utilizadas em sistemas Unix e seus derivados como o Linux.

103

5.2.4. BERKELEY SOCKETS O “Berkeley Sockets” é uma API genérica para programação baseada em protocolos de comunicação orientados a conexão, como TCP e orientados a datagrama, como UDP. A implementação das chamadas de sistema dessa interface são padronizadas em todos sistemas operacionais Unix e estende-se para muitas outras plataformas. A padronização da interface para “sockets” foi feita originalmente no escopo do sistema operacional chamado Unix BSD (Berkeley Software Distribution), por isso eles são chamados de “Berkeley Sockets”.

5.2.5. POSTFIX O Postfix é um agente para transferência 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 características principais estão: facilidade na administração, velocidade, segurança 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 distribuição não comercial livre (gratuita e de código fonte aberto) de GNU/Linux e de um grupo de voluntários que o mantêm (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: atualizações fáceis a partir de versões antigas, instalações facilitadas de novos pacotes e remoções 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. ESPECIFICAÇÃO Nessa seção são apresentados alguns diagramas UML 2.0, que descrevem as características, requisitos e funcionamento do “software” para monitoramento desenvolvido chamado de JDaemon. Os diagramas UML utilizados são: diagrama de casos de uso, diagrama de classes, diagrama de transição 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 Capítulo 4) utilizando o “software” embarcado cliente TCP é modelado como um ator e interage diretamente com os casos de uso “Estabelecer conexão 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 notificação de alarme por E-mail” também o são. 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” são obrigatoriamente executados. Uma observação importante é que os casos de uso “Disparar Alarme” e “Realizar amostragem da temperatura” possuem uma semântica de relação “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 padrão POSIX (“Pthread”). Basicamente, no escopo do JDaemon para se criar um “thread” basta que se crie uma classe que estenda “JThread” e implemente o método virtual puro “run”. O trecho de código implementado no método “run” será o trecho que executará de forma concorrente. Foram criadas três classes “JThread”: JThreadAlarme, JThreadLOG e JThreadBanco. A primeira é responsável pela notificação de alarmes de temperatura, a segunda é responsável por fazer amostragem de temperatura e armazenar em um arquivo de LOG e a última é responsável por fazer a mesma amostragem, mas utilizando um banco de dados. No pacote “Recursos Unix” são apresentados os recursos típicos de sistemas Unix que foram utilizados na implementação do JDaemon. Apesar de esses recursos serem apresentados no diagrama como classes, eles são recursos de baixo nível do Unix implementados C e, portanto, tipicamente procedurais. Os recursos do pacote Unix utilizados foram: “sockets”, “alarm” e “mutex”. Como dito anteriormente, esses recursos são implementados em C pelos 106

sistemas Unix, mas a forma com que foram apresentados no diagrama de classes pode ser utilizada como sugestão para encapsulá-los em classes. A classe JDaemon representa o “daemon” propriamente dito. Ela utiliza todas as classes apresentados no diagrama e sua existência completa só faz sentido se essa condição for satisfeita. Portanto, o relacionamento entre o “daemon” e as demais “classes” foi modelado como uma composição (agregação 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 funções, classes, variáveis globais, constantes, estruturas (“struct”), dentre outros.

Figura 5.12 - Diagrama de classes do JDaemon.

107

5.3.3. DIAGRAMA DE TRANSIÇÃO DE ESTADOS Na Figura 5.13 pode ser visto o diagrama de transição de estados simplificado do JDaemon. Inicialmente, o mesmo está no estado “inicializando”. Logo em seguida passa para o estado “esperando conexão” e permanece neste até que o “hardware” microcontrolado se conecte ao mesmo. Após a conexão 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 não 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 seqüencialmente os estados “registrado alarme em arquivo de LOG”, “registrando alarme em banco de dados” e “enviando notificação de alarme por e-mail”. Caso o valor da temperatura esteja dentro dos limites aceitáveis, o JDaemon vai para o estado “habilitando amostragem”. Se já houve um estouro no temporizador de amostragem, o próximo 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 não tenha havido um estouro no temporizador de amostragem, significa que ainda é muito cedo para registrar valores, então o JDaemon vai para o estado “recebendo temperatura” novamente a fim de receber uma temperatura mais atual para armazenar no próximo estouro do “timer” de amostragem. Assim que receber uma nova temperatura, se a mesma estiver nos limites aceitáveis, 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 implementação do JDaemon pode ser observado na transição de saída do estado “criando threads de registro”. Além do fluxo (thread) principal são criados outros dois fluxos (threads) alternativos. Isso é importante, porque o fluxo principal retorna imediatamente para o estado “esperando conexão”, a fim de estabelecer uma nova conexão e receber um novo dado de temperatura. Dessa forma, enquanto os dois “threads” ainda estão executando suas atividades, o “thread” principal já está monitorando a temperatura novamente e pode responder o mais rápido possível à ocorrência de uma alarme. Nessa situação fica bem perceptível o poder da programação “multithread”.

108

Figura 5.13 - Diagrama de transição 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 operações foram abstraídas para simplificar o diagrama. Inicialmente é realizada a inicialização dos recursos utilizados pelo JDaemon: estruturas de dados, variáveis globais, mutex, “alarm” e “sockets”. Posteriormente, o mesmo fica esperando conexões TCP em uma porta específica. Assim que um cliente TCP (mais precisamente o “hardware” microcontrolado) realiza a conexão, o mesmo disponibiliza um dado de temperatura. Então, o JDaemon verifica se o valor do dado está dentro dos limites aceitáveis. Caso esteja, ele verifica se o tempo de amostragem já foi estabelecido. Em caso positivo, são 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 não esteja dentro dos limites definidos, um “thread” de alarme é criado e o mesmo fica responsável por enviar um “e-mail” para o administrador do sistema, notificando o alarme e também por registrar a ocorrência do alarme no banco de dados e no arquivo de LOG. 109

O acesso aos recursos compartilhados é gerenciado por duas regiões críticas: uma para acesso ao arquivo e outra para o banco de dados. Isso é necessário devido o JDaemon criar “threads” que utilizam recursos compartilhados, sendo possível inclusive que dois ou mais “threads” tentem acessar o recurso de forma concorrente gerando assim inconsistências. Em relação ao banco de dados, o tratamento de exclusão mútua foi feito mais especificamente para a abertura/fechamento da conexão com o banco de dados. Caso um “thread” tente utilizar o arquivo ou banco de dados e não consiga, uma notificação 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 redundância do registro de informações. Caso fosse utilizada só uma fonte de registro (arquivo ou banco de dados), isso não seria possível. As ações de registro de erro de abertura do arquivo ou conexão com o banco de dados são descritas como atividades simples para diminuir o diagrama, mas elas também necessitam de um conjunto de ações (ou atividades) para sua realização. Diversos estereótipos foram utilizados na tentativa de facilitar a compressão do diagrama. As atividades que são executadas por um “thread” específico podem ser identificados pelo estereótipo “ThreadX”, onde “X” pode ser Alarme, Banco ou LOG. Dessa forma, cada atividade (ou ação) do diagrama é apresentada de forma relacionada ao “thread” que a executa. As operações “lock” e “unlock” das variáveis “mutex”, que gerenciam o acesso a uma região crítica, são representadas como estereótipo, associadas também a que recurso compartilhado as mesmas estão gerenciando: arquivo ou banco de dados.

110

Figura 5.14 - Diagrama de atividades do JDaemon.

111

5.4. IMPLEMENTAÇÃO O “software” para aquisição remota de temperatura (JDaemon) foi desenvolvido para ser um “daemon” (seção 5.1.1), ou seja, um programa que executa como um serviço e toma decisões automaticamente sem a intervenção do usuário. O mesmo foi programado utilizando as linguagens C/C++, é majoritariamente orientado a objetos e utiliza alguns recursos POSIX, que são programados em C originalmente. A linguagem C/C++ foi escolhida por questões de desempenho e suporte a recursos POSIX. Para estabelecer conexão remota foram utilizados os “Berkeley Sockets” (seção 5.2.4), que são um exemplo de implementação do mecanismo de troca de mensagens (seção 5.1.6.1) para comunicação interprocessos (seção 5.1.6). O JDaemon atua como um servidor TCP, que espera conexões remotas em uma porta especifica. Para registro de informações foram utilizados arquivos de LOG e o banco de dados MySQL 5.0 (seção 5.2.2), a fim de garantir redundância e uma maior confiabilidade no registro das informações. Caso haja problema em um dos mecanismos de armazenamento, o outro pode ser utilizado para completar a atividade. O JDaemon é um programa que utiliza múltiplos fluxos de execução para realização de suas atividades. Para implementar essa características foram utilizados “threads” (seção 5.1.4) ao invés de processos (seção 5.1.3), pois os mesmos utilizam menos recursos e são mais adequados para serem criados e destruídos dinamicamente (seção 5.1.5). O sistema operacional especificado para executar o JDaemon é o Debian 4 Etch (seção 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 método virtual puro “run”. Cada classe que deseje executar em “thread” deve estender a classe “JThread” e implementar o método “run”, que é o método executado de forma concorrente. Encapsular em uma classe um recurso de baixo nível implementado em C como as “pthreads” não foi simples e teve um custo muito caro em termos de tempo e depuração. Além disso, a classe “ofstream” da biblioteca “fstream.h”, que é a classe padrão C++ para escrita em arquivo, talvez por incompatibilidade, não pôde ser utilizada com sucesso para abrir um arquivo dentro do método “run” de uma classe “JThread”, que é um “POSIX thread” cuja implementação original é em C. Então, as funções da biblioteca “stdio.h” da linguagem C para manipulação de arquivos foram utilizadas ao invés das classes C++. Para conexão com o bando de dados MySQL 5.0 foi utilizada a API em C, ao invés 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 múltiplos “threads” criados pelo JDaemon, os trechos de código relativos a operações com o banco de dados e arquivo de LOG são regiões críticas e representam recursos compartilhados entre os vários “threads”. Logo, as operações nessas regiões críticas devem ser realizadas de forma atômica, para garantir exclusão mútua no acesso aos recursos. Para garantir exclusão mútua foi utilizado o tipo “mutex” da biblioteca “pthread.h” (POSIX Thread), que é exemplo do mecanismo de sincronização Mutex (seção 5.1.6.1) ou semáforo binário (seção 5.1.6.1). 112

Apesar de o JDaemon receber informações em intervalos de tempo muito pequenos, na ordem de segundos. O mesmo não armazena todas essas informações, a fim de evitar o excesso e redundância de dados no arquivo de LOG e no banco de dados. Os dados de temperatura são recebidos a cada 10 segundos, por exemplo, são analisados e se o valor for abaixo do limite aceitável, o “thread” de alarme é ativado para armazenar o dado no banco e no arquivo de LOG e enviar um “e-mail” com a notificação de alarme para o administrador do sistema. Caso a temperatura esteja no nível aceitável, a mesma é descartada até que o intervalo para amostragem de temperatura tenha sido estabelecido. Nessa situação dois “threads” são 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”) disponível 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 execução 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. Além dos registros, o “thread” de alarme é responsável por enviar um “e-mail” para o administrador do sistema, utilizando para isso o Postfix (seção 5.2.5). Problemas de registro excessivo de dados também podem ocorrer no registro do alarme. Assim que a ocorrência de alarme é identificada, verifica-se se a temperatura atual é menor que a temperatura anterior subtraída de um erro predefinido. Se for, ela deve ser registrada. Senão, deve ser verificado se o evento de alarme é relativo a uma nova ocorrência 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 ocorrência, ou seja, se passaram 10 minutos em relação ao evento anterior, por exemplo. O “thread” de alarme faz muitas atividades de forma seqüencial: escreve no arquivo, no banco de dados e envia um “e-mail”. Por que não criar um “thread” para cada uma dessas atividades? De fato é uma idéia interessante e completamente possível. Entretanto, criar muitos “threads” dentro de outro “thread” pode ser uma fonte inicial de problemas de desempenho. Então, a implementação atual foi feita da forma mais conservadora possível. 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” genérica, que permite que novos “threads” sejam criados a partir dela.

113

6. SISTEMA WEB PARA MONITORAMENTO DE TEMPERATURA Neste capítulo são apresentadas informações relativas ao desenvolvimento do sistema WEB. Esse “software” é utilizado para possibilitar que as informações de temperatura, armazenadas no banco de dados pelo “JDaemon”(Capítulo 5), possam ser apresentadas através de gráficos e relatórios. Além disso, através do sistema WEB, essas informações podem ser acessadas através da Internet. Na seção sobre as considerações teóricas, inicialmente são 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 questão. Em seguida, é explicado o conceito de “JavaBean”, o padrão MVC para arquitetura de “software” e a arquitetura em três camadas. Posteriormente, é apresentado de forma breve o conceito de “padrões de projeto”, bem como os padrões clássicos, que são apresentados divididos nas categorias: padrões estruturais, de criação e comportamentais. Em seguida, os padrões de projeto utilizados no sistema WEB são apresentados com mais detalhes. Na seção de metodologia são apresentadas as ferramentas e tecnologias utilizadas. Por fim, a especificação do sistema é apresentada, através de um diagrama de casos de uso e de três diagramas de classe, que descrevem a arquitetura lógica do sistema de forma incremental. Ou seja, cada diagrama possui melhorias e novas características em relação ao anterior.

6.1. CONSIDERAÇÕES TEÓRICAS Essa seção apresenta as considerações teóricas 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 programação orientada a objetos, desenvolvida pela Sun Microsystems (SUN, 2009). Uma das particularidades do Java é que, diferente das linguagens convencionais que são compiladas para código de máquina, o Java é compilado para um código intermediário, chamado de “bytecode”, que é executado por uma máquina virtual. Algumas das principais características do Java são: • • • • •

Orientação a objeto - Baseado no modelo de Smalltalk, Simula67 e C++; Portabilidade - Independência de plataforma; Recursos de Rede - Possui extensa biblioteca que facilita a utilização com protocolos TCP/IP, como HTTP e SMTP; Segurança - Pode executar programas via rede com restrições de execução; É distribuída com um vasto conjunto de bibliotecas (ou APIs); 114

• • •

Possui facilidades para criação de programas distribuídos e multitarefa; Desalocação automática de memória, através de coletor de lixo (“garbage collector”); Carga Dinâmica de Código - Programas em Java são formados por uma coleção de classes armazenadas independentemente e que podem ser carregadas no momento de utilização.

6.1.1.1. JAVA EE A Java EE (“Enterprise Edition”) é uma plataforma de “software” utilizada para o desenvolvimento de aplicações distribuídas 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, distribuído, tolerante a falha, baseado em módulos 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 distribuído para aplicações coorporativas (“enterprise”). A lógica da aplicação é dividida em componentes de acordo com sua função, e vários componentes da aplicação podem ser instalados em máquinas diferentes, dependendo da camada da plataforma JEE que o componente da aplicação pertence. Na Figura 6.2. (JAVAEE, 2008) podem ser vistas duas aplicações JEE multicamadas divididas nas camadas descritas a seguir: 115

• • • •

“Client-tier”: componentes que executam na máquina 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 transações são exemplos de serviços que executam em um servidor EIS.

Figura 6.2 - Dois exemplos de aplicações JEE multicamadas.

Apesar de uma aplicação JEE poder consistir de três ou quatro camadas como foi apresentado na Figura 6.2 (JAVAEE, 2008), aplicações JEE multicamadas geralmente são consideradas do tipo três camadas físicas, já que são distribuídas em três localizações: máquinas cliente, máquinas servidoras JEE e banco de dados ou máquinas de transação. Aplicações três camadas que executam dessa forma estendem o modelo padrão cliente-servidor de duas camadas colocando um servidor de aplicação multicamada entre a aplicação cliente e a camada de persistência. No escopo desse trabalho, apenas os componentes do “Web Container” foram utilizados. Os componentes WEB do JEE providenciam extensão dinâmica das capacidades do servidor WEB. Esses componentes podem ser Java “Servlets” (seção 6.1.1.1.1), páginas JSP (6.1.1.1.2) ou serviços WEB do tipo “endpoint”. A interação entre um cliente e uma aplicação WEB pode ser vista na Figura 6.3 (JAVAEE, 2008). O cliente envia uma requisição HTTP para o servidor WEB. O servidor WEB que implementa o “Java Servlet” e “Java Server Pages (JSP)” converte a requisição em um objeto do tipo HTTPServletRequest. Esse objeto é encaminhado para um componente WEB, que pode interagir com “JavaBeans” (seção 6.1.1.1.4) ou com um banco de dados, a fim de gerar conteúdo dinâmico. O componente WEB posteriormente pode gerar um HTTPServletResponse ou repassar a requisição 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 interação entre um cliente e uma aplicação WEB.

6.1.1.1.1. “SERVLET”  Os “servlets” são basicamente classes Java que podem dinamicamente processar requisições e construir respostas HTTP. Dessa forma os “servlets” propiciam novos recursos ao servidor, sendo em geral definidos como extensões dos servidores. O “servlet” disponibiliza uma interface para o servidor WEB (ou servidor de aplicação) através de uma API. As aplicações baseadas em “servlets” geram conteúdo dinâmico (normalmente HTML) e interagem com os clientes utilizado o paradigma “request/response”. Os “servlets” geralmente utilizam o protocolo HTTP, mas não são restritos a ele e foram implementados de forma genérica e independente do protocolo de comunicação utilizado. Além disso, o “servlet” necessita de um “container WEB” para ser executado.

6.1.1.1.2. JSP (“JAVA SERVER PAGES”) As páginas JSP são documentos baseados em texto que executam como “servlet”, mas que permitem uma abordagem mais natural para desenvolvimento de conteúdo estático de apresentação de uma página WEB. As páginas JSP são uma alternativa ao ASP e PHP. Além disso, as JSPs podem ser utilizadas para acessar bancos de dados, obter informações de formulários, manipular arquivos em formato texto e obter informações sobre o visitante e o servidor. Dessa forma, as JSPs permitem que conteúdo dinâmico seja gerado e apresentado em uma página WEB. Nessas situações, o conteúdo dinâmico é geralmente obtido através de códigos Java e apresentado através de HTML. Logo, as páginas JSP permitem a utilização de código Java e HTML no mesmo arquivo.

117

Tanto “servlets” quanto “JSPs” podem ser utilizados de forma intercambiável, mas cada um é mais adequado para um tipo de funcionalidade. Os “servlets” são mais adequados para fazer controle da aplicação e processamento dos dados. Já as páginas JSP são mais adequadas para geração de texto de apresentação de dados baseados em HTML, XML, dentre outros.

6.1.1.1.3. JSTL (“JSP STANDARD TAG LIBRARY”) Apesar de as páginas JSP serem mais adequadas para geração de conteúdo WEB dinâmico, elas adicionam o inconveniente de tornar o código pouco legível devido a utilização de código Java e HTML de forma “entrelaçada”. Esse inconveniente foi minimizado com o desenvolvimento da JSTL. JSTL consiste de uma biblioteca de “tags” JSP padronizadas, onde cada uma possui um propósito específico, permitindo escrever páginas JSP sem código Java, aumentando assim a legibilidade dos códigos de uma página JSP. Então, basicamente, uma página JSTL é uma página JSP com “tags” JSTL. Cada “tag” realiza um tipo de processamento, que é similar à funcionalidade que seria obtida utilizando código Java.

6.1.1.1.4. JAVABEANS Os JavaBeans são componentes de “software” Java. De acordo com a Sun Microsystems (SUN, 2009) , os JavaBeans são “componentes reutilizáveis 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 convenções de nomenclatura de método, construtores e comportamento. Essas convenções permitem a identificação de um JavaBean por parte das ferramentas e as mesmas podem então manipulá-los de forma adequada. As convenções que uma classe deve seguir são: • • • •

Implementar a interface  java.io.Serializable (que possibilita a persistência e restauração do estado do objeto da classe); Possuir um construtor sem argumentos; Permitir que as suas propriedades sejam acessíveis através de métodos "get" e "set", seguindo o padrão de nomenclatura; Possa conter qualquer método de tratamento de eventos.

118

6.1.2. MVC E ARQUITETURA EM 3 CAMADAS O conceito da tríade de classes Model-View-Controller (MVC) foi utilizado, originalmente, para construir interfaces gráficas com o usuário na linguagem de programação Smalltalk-80 (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) . A abordagem MVC é composta de três tipos de objetos. O Modelo (“Model”) é o objeto de aplicação, o controlador (“Controller”) é o que define o comportamento da interface, a partir das informações submetidas pelo usuário e a Visão (“View”) é responsável pela apresentação das informações na tela. Antes do MVC, os projetos de interface de usuário tendiam a agrupar esses objetos, gerando um código monolítico. O MVC separa esses objetos a fim de aumentar a reutilização e flexibilidade. Na Figura 6.4 (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) pode ser vista uma das grandes vantagens da utilização do MVC (os controladores foram abstraídos para simplificar a figura). A partir dos dados disponibilizados por um único modelo, diferentes formas de apresentações foram construídas. Isso é possível, porque não há um acoplamento forte entre os dois objetos, ou seja, o objeto de modelo não possui códigos relacionados à lógica de aplicação. Então, fica como responsabilidade da classe de visão ter acesso aos dados e incluir todo o código para apresentá-los da forma desejada. Caso o código fosse monolítico e já existisse uma apresentação em forma de tabelas, por exemplo, mudar para um gráfico tipo “pizza” não seria uma tarefa agradável, já que haveria códigos relacionais ao modelo, controle e apresentação em um mesmo bloco e se perderiam, então, as capacidades de reutilização e a flexibilidade. A abordagem MVC fica ainda mais evidente, se diferentes tecnologias de visão forem utilizadas. Por exemplo, uma aplicação “Desktop” necessita ser convertida em uma aplicação WEB: se o modelo MVC foi bem utilizado, duas das três camadas lógicas (Controle e Modelo) serão preservadas, mudando apenas a tecnologia da visão, que é obrigatória neste caso. Novamente, se o código fosse monolítico, todas as camadas teriam sua preservação e reutilização comprometidas.

Figura 6.4 – MVC: flexibilidade na apresentação do mesmo conjunto de dados.

O objetivo da arquitetura em três camadas é a separação das funcionalidades de um “software” utilizando camadas. Em uma arquitetura de três camadas se cria uma camada para 119

lógica de apresentação, lógica de negócio e a lógica de acesso aos dados (conexão com banco de dados). Essa separação torna o sistema mais flexível e reutilizável, pois as camadas podem ser alteradas de forma independente. Além disso, se a interface de comunicação entre as mesmas permanecer inalterada, as camadas podem ser alteradas ou até mesmo substituídas, sem influenciar nas demais. Na Figura 6.5 (NETO; NADALETE; GENNARI; FREITAS 2009) pode ser visto o poder de reutilização e flexibilidade da arquitetura em três camadas, onde um mesmo sistema é utilizado por duas tecnologias de visão e de acesso a dados persistentes diferentes. Ou seja, a camada de lógica de negócio, que é a parte principal da aplicação, permanece praticamente intacta e as camadas que são dependentes de tecnologias podem ser substituídas ou alteradas quando for necessário.

Figura 6.5 - Representação de uma arquitetura em três camadas utilizando diferentes tecnologias de visão e persistência.

Certamente, os conceitos MVC e arquitetura em três camadas são similares, mas não iguais. Na verdade, há uma grande discussão em torno desses conceitos: alguns autores consideram que são equivalentes e outros não. Mas, não é interessante entrar no mérito dessa discussão e sim perceber que não seria um erro simplesmente nomear as camadas da arquitetura em três camadas com a nomenclatura do MVC, a fim de simplificar e tornar mais intuitiva o seu significado. Então, na arquitetura em três camadas os nomes seriam: Visão – Lógica de apresentação; Controle – Lógica de negócio; Modelo – Objetos a serem persistidos pela lógica de acesso a dados. Um bom argumento para se dizer que a abordagem MVC e a arquitetura em três camadas não são idênticas pode ser visto se compararmos as Figura 6.5 e 6.6 (BALAZS, 2009). As camadas intermediárias do MVC (Controle) e da arquitetura em três camadas (lógica de negócio) possuem papéis diferentes. Além disso, o MVC permite que a Visão (camada mais “superior”) se comunique diretamente com o Modelo (camada mais “inferior”), já na arquitetura em três camadas a camada mais superior (Apresentação) só pode se comunicar através da camada intermediária (Lógica de negócio) com a camada mais inferior (Acesso a dados). Certamente isso acontece porque os objetivos dos dois modelos são diferentes: um deles foi idealizado para construção de interfaces gráficas e o outro para aplicações de propósito geral, 120

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

Figura 6.6 - Relacionamento entre as camadas do MVC.

6.1.3. PADRÕES DE PROJETO De acordo com (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) , “Projetar um software orientado a objetos é difícil, mas projetar “software” reutilizável orientado a objetos é mais difícil ainda”. É muito comum no desenvolvimento de “software” se ter a sensação de que “isso  já foi visto antes”, ou seja, um mesmo problema em um contexto diferente. Então, fica a dúvida: “como seria possível aplicar uma solução anterior a esse novo projeto?”. Uma das respostas para essa pergunta seria a aplicação de padrões de projeto. Os padrões de projeto permitem a reutilização eficaz de soluções e arquiteturas bem sucedidas, para construir programas orientandos a objetos, garantindo flexibilidade, facilidade de manutenção e evolução. A utilização de padrões de projeto pode reduzir o tempo e complexidade do processo de implementação de um “software”. Além disso, um “software” orientado a objetos bem projetado possibilita a reutilização, ou seja, o emprego de componentes desenvolvidos anteriormente em projetos futuros. Em termos de código, os padrões 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 padrões, seu contexto, escopo e aplicação. Ou seja, deve-se analisar o problema e identificar qual padrão pode ser aplicado satisfatoriamente para resolver o problema. Inicialmente, esse processo de identificação é bem difícil. 121

6.1.3.1. O QUE É UM PADRÃO DE PROJETO? Os padrões de projeto foram propostos inicialmente por Christopher Alexander para problemas de arquitetura na construção civil. Ele afirmava que “cada padrão descreve um problema no nosso ambiente e o núcleo da sua solução, de tal forma que você possa utilizar esta solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira”. Embora este comentário se refira a padrões de arquitetura em construção de casas, prédios, cidades, dentre outros, o seu contexto foi trazido para a computação 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 padrões de arquitetura para o mundo da computação e descobriram contextos onde a mesma solução poderia ser aplicada várias vezes. Assim, o conceito de padrão de projeto possui quatro elementos essenciais: • • • •

O nome do padrão é uma referência que pode ser utilizada para descrever um problema de projeto, suas soluções e conseqüências em uma ou duas palavras; O problema descreve quando aplicar o padrão; A solução descreve os elementos que compõem o projeto, suas responsabilidades, relacionamentos e colaborações; As conseqüências são os resultados, vantagens e desvantagens da aplicação do padrão.

Resumindo, um padrão se propõe a nomear, abstrair e identificar os aspectos mais importantes de um projeto, a fim de tornar esses aspectos um projeto orientado a objetos reutilizável.

6.1.3.2. OS PADRÕES DE PROJETO Nesta seção são apresentados de forma breve os padrões de projeto e objetivos originalmente apresentados por (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) . São vinte três padrões, divididos nas classificações: padrões de criação, comportamentais e estruturais.

6.1.3.2.1. PADRÕES DE CRIAÇÃO Os padrões de criação basicamente abstraem o processo de instanciação de um objeto. Dessa forma, eles ajudam a tornar um sistema independente de como seus objetos são criados, compostos e representados. Um padrão de criação de classe utiliza o mecanismo de herança da orientação a objetos, para variar a classe que é instanciada. Já o padrão de criação de objeto delegará a responsabilidade da instanciação a outro objeto.

122

Padrões pertencentes a essa categoria possuem duas características marcantes: • •

Todos encapsulam conhecimento sobre quais classes concretas são utilizadas pelo sistema; Ocultam o modo como as instâncias destas classes são criadas e compostas.

Os padrões de criação se tornam importantes à medida que os sistemas evoluem e passam a depender mais da composição de objetos do que da herança entre classes. Nessa situação, a definição de um conjunto menor de comportamentos fundamentais passa a ser mais importante que a codificação rígida de um conjunto fixo de comportamentos. A partir de um conjunto menor e mais flexível de comportamentos pode-se compor comportamentos mais complexos e customizados para o problema em questão. Os padrões de projeto de criação propostos pelo GoF (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) podem ser vistos na Tabela 6.1.

Tabela 6.1 - Padrões de projeto de criação.

Padrão

Finalidade

Abstract Factory

Fornecer uma interface para se criar conjuntos de objetos que se relacionam ou que são dependentes, sem especificar a classe concreta do mesmo.

Builder

Facilitar a criação de um objeto complexo, de modo que este processo possa criar diferentes representações do objeto.

Factory Method

Fornecer uma interface para criar um objeto, mas deixar que as subclasses decidam que classe instanciar

Prototype

Especificar os tipos dos objetos a serem criados via uma instância protótipo, para que depois novos objetos sejam copiados a partir dele.

Singleton

Garantir que um objeto tenha uma única instância e fornecer um acesso global à mesma.

6.1.3.2.2. PADRÕES ESTRUTURAIS Os padrões estruturais se preocupam com a forma como os objetos e classes são compostos, a fim de formar estruturas maiores. Os padrões estruturais de classes utilizam herança para compor interfaces ou implementações. Por exemplo, a herança múltipla utiliza duas ou mais classes para compor uma terceira maior e mais poderosa, pois esta combina as propriedades das suas classes “pai”. Já os padrões estruturais de objetos não se preocupam com a composição de interfaces ou implementações, mas em descrever maneiras de compor objetos para obter novas funcionalidades. A flexibilidade obtida pela composição de objetos provém da 123

habilidade e capacidade de mudar-se essa composição em tempo de execução, o que seria impossível com composições estáticas baseadas em classes. Os padrões de projeto estruturais propostos pelo GoF (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) podem ser vistos na Tabela 6.2. Tabela 6.2 - Padrões de projeto estruturais.

Padrão

Finalidade

Adapter

Converte uma interface em outra interface, o que permite que classes com interfaces incompatíveis trabalhem em conjunto.

Bridge

Separa uma abstração de sua implementação, de modo que as duas possam variar (ou trabalhar) independentemente.

Composite

Compor objetos em estruturas de árvores para representar hierarquias todo-parte.

Decorator

Fornecer de forma dinâmica responsabilidades adicionais a objetos.

Facade

Fornecer uma interface unificada para um conjunto de interfaces em um subsistema.

Flyweight

Procura subdividir as informações comuns a diversos objetos em um único componente. Os dados particulares e únicos desses objetos passam a ser utilizados como parâmetros de métodos.

Proxy

Provê uma referência e/ou substituto para controlar o acesso a um objeto, funcionando como um substituto temporário do mesmo.

6.1.3.2.3. PADRÕES COMPORTAMENTAIS Os padrões comportamentais se preocupam com os algoritmos e a atribuição de responsabilidade entre objetos. Esses padrões não descrevem apenas padrões de objetos ou classes, mas padronizam também a forma como os objetos devem se comunicar. Os padrões criam fluxos de controle complexos, que são difíceis de serem seguidos em tempo de execução. Basicamente, eles abstraem o fluxo de controle do programador, para permitir que o mesmo se concentre apenas na maneira como os objetos são interconectados. Os padrões comportamentais para classes utilizam a herança para distribuir o comportamento entre as classes. Já os padrões comportamentais para objetos utilizam a composição de objetos no lugar de herança. Alguns descrevem como um grupo de objetos relacionados cooperam para execução de uma tarefa, que individualmente não teriam capacidade de realizar. 124

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

Padrão

Finalidade

Chain of Responsability

Evita o acoplamento do remetente de uma solicitação ao seu destinatário, dando a mais de um objeto a chance de tratar a situação.

Command

Encapsula uma solicitação como um objeto, de forma que permita a parametrização com os clientes com diferentes solicitações, filas ou registro de solicitações a fim de permitir o cancelamento das mesmas.

Interpreter

Dada uma linguagem, define a representação para sua gramática juntamente com um interpretador que usa a representação para interpretar as sentenças nessa linguagem.

Iterator

Fornece uma maneira de acessar seqüencialmente os elementos de um objeto agregado, sem expor sua representação subjacente.

Mediator

Define um objeto que encapsula como um conjunto de objetos interage.

Memento

Sem violar o encapsulamento, captura e externaliza um estado interno de um objeto, de modo que possa posteriormente ser restaurado para este estado.

Observer

Define uma dependência de um para muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são automaticamente notificados e atualizados.

State

Permite que um objeto altere seu comportamento quando seu estado interno muda.

Strategy

Define uma família de algoritmos, encapsulando cada um deles a fim de torná-los intercambiáveis.

Template Method

Define o esqueleto de um algoritmo em uma operação, postergando a definição de alguns passos para subclasses.

Visitor

Representa uma operação a ser executada sobre os elementos da estrutura de um objeto, permitindo que seja possível definir uma nova operação sem mudar as classes dos elementos sobre os quais opera.

125

6.1.4. PADRÕES UTILIZADOS Nessa seção são descritos, de forma um pouco mais detalhada, os padrões utilizados no desenvolvimento do sistema WEB. São descritos os padrões de projeto clássicos “Singleton”, “Facade” e “Command”, além do padrão para persistência DAO (Data Access Object) e para arquitetura “Layer”. Esses dois últimos não foram originalmente catalogados por (GAMMA; HELM; JOHNSON; VLISSIDES, 1994) . Os padrões são apresentados de forma breve, baseando-se no problema que o padrão busca solucionar, na solução utilizada pelo padrão e nas conseqüências de utilizar o mesmo. Um assunto fundamental, que se refere à implementação dos padrões, não será abordada, pois foge um pouco do escopo desse trabalho, mas é de fundamental importância para se poder utilizar os padrões. Na seção 6.3.3 são feitos breves comentários sobre a implementação desses padrões no escopo do sistema WEB em desenvolvimento.

6.1.4.1. “SINGLETON” O “Singleton” é um padrão de criação. O objetivo do mesmo é garantir que uma classe tenha uma única instância e forneça um ponto de acesso global para a mesma.

6.1.4.1.1. PROBLEMA Como garantir que uma classe tenha uma única instância e que esta seja de fácil acesso?

6.1.4.1.2. SOLUÇÃO Se for buscada uma solução na programação estruturada, uma variável global poderia resolver o problema, mas qualquer parte do código poderia alterar essa variável, mesmo as partes que não deveriam. Isso é um grande inconveniente, já que se tem pouco controle do acesso à variável e pode-se promover insegurança no estado da mesma. Uma solução melhor é fazer com que a própria classe seja responsável por manter o controle sobre sua única instância. A classe então garante que nenhuma outra instância deverá ser criada (através da interceptação das solicitações para criação de novos objetos), bem como fornecer um meio para acessar essa única instância. O padrão “Singleton” é adequado quando: •

•

For preciso haver uma única instância de uma classe, e essa instância necessitar fornecer acesso através de um ponto único e bem conhecido na aplicação; A instância única tiver que ser extensível através de subclasses, possibilitando às classes “clientes” utilizar uma instância estendida sem alterar o seu código.

126

6.1.4.1.3. CONSEQUÊNCIAS O padrão “Singleton” quando utilizado no escopo de uma aplicação traz as seguintes conseqüências: •

•

•

Acesso controlado à única instância da classe. Como a classe “Singleton” encapsula a sua única instância, possui total controle sobre como e quando a instância é acessada; Conjunto de entidades (variáveis ou objetos) reduzido. O padrão “Singleton” minimiza o uso de variáveis globais e evita a utilização de variáveis desse tipo que são declaradas com objetivo de serem únicas, ou seja, possuir uma única instância; Permite um número variável de instâncias. Se a aplicação necessitar de um número customizado de instâncias, o padrão “Singleton” garante essa possibilidade e ainda apresenta garantias de controle sobre o número de instâncias que deverão ser criadas.

6.1.4.2. “FACADE” Fornece uma interface centralizada de acesso a serviços providos por subsistemas, através de uma interface de mais alto nível.

6.1.4.2.1. PROBLEMA Como fornecer uma interface unificada para um conjunto de interfaces em um subsistema? Como minimizar a comunicação e as dependências em um subsistema?

6.1.4.2.2. SOLUÇÃO Estruturar um sistema em diversos subsistemas ajuda a diminuir sua complexidade. Além disso, um objetivo comum em projetos é minimizar a comunicação e a dependência 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 padrão Facade deve ser utilizando quando: • • •

Se desejar fornecer uma interface simples para um subsistema complexo; Existirem muitas dependências entre classes “clientes” e classes de implementação de um determinado serviço ou funcionalidade; Se desejar estruturar um subsistema em camadas.

127

6.1.4.2.3. CONSEQUÊNCIAS As conseqüências de utilizar o padrão “Facade” em um projeto são: •

•

Isolar os usuários (classes “clientes”) dos componentes do subsistema, reduzindo dessa forma o número de objetos que os clientes devem utilizar e tornando o subsistema mais fácil de usar; Diminui o acoplamento entre o subsistema e seus clientes. Um fraco acoplamento entre os componentes possibilita que alterações e até mesmo variações nos componentes sejam feitas sem afetar as classes “clientes”.

6.1.4.3. “COMMAND” Encapsula uma solicitação como um objeto, possibilitando parametrizar clientes com diferentes solicitações, permitindo também enfileirar ou fazer o registro (log) de solicitações e suportar o processo de desfazer operações.

6.1.4.3.1. PROBLEMA Como permitir que objetos específicos façam solicitações de objetos da aplicação não especificados, transformando a própria solicitação em um objeto?

6.1.4.3.2. SOLUÇÃO Basicamente, o padrão “command” encapsula as solicitações como objetos. Dessa forma, é possível parametrizar os clientes através dos objetos (serviços) solicitados e ainda armazenar ou repassar esses objetos. O padrão “command” é adequado quando se deseja: • • • • •

Parametrizar objetos por uma ação a ser executada; Especificar, enfileirar e executar solicitações em tempos diferentes; Suportar o processo de desfazer operações; Suportar registro (“logging”) de mudanças a fim de replicá-las, no caso de uma queda do sistema; Estruturar um sistema em torno de operações de alto nível construídas sobre operações primitivas.

128

6.1.4.3.3. CONSEQUÊNCIAS As conseqüências de utilizar o padrão “Command” em um projeto são: • • • •

Desacoplamento entre o objeto que invoca a operação e aquele que sabe como executá-la; Os objetos produzidos pelo padrão podem ser manipulados e estendidos como quaisquer outros objetos; É possível unir comandos para formar um comando composto; É simples adicionar novos comandos porque não é necessário mudar nenhuma das classes existentes.

6.1.4.4. DAO (DATA ACCESS OBJECT) O padrão DAO fornece um meio prático de acessar e recuperar informações de uma base de dados, de forma a separar as outras camadas da aplicação da interação com o banco de dados.

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

6.1.4.4.2. SOLUÇÃO É muito comum encontrar nas linguagens de programação, APIs para os mais comumente utilizados SGBD existentes. Mas, caso um sistema deseje realizar uma migração na tecnologia de persistência, todos os arquivos que manipulam a base de dados deverão ser alterados, para utilizar a API da tecnologia de persistência para a qual o sistema será migrado. Para resolver o problema de acoplamento entre a tecnologia de persistência e as classes que manipulam a base de dados, o padrão DAO fornece uma interface independente, que deve ser utilizada para persistir objetos de dados. Basicamente, a idéia é colocar todas as funcionalidades de acesso e conexão à base de dados em um só local, tornando simples sua manutenção. Resumindo, a interface DAO especifica como são as assinaturas dos métodos (parâmetros, nome, tipo de retorno, dentre outros) e as classes DAO se responsabilizam por implementar esses métodos. Dessa forma, não importa se a implementação é feita utilizando arquivos ou um SGBD, por exemplo, já que a interface é unificada e apenas a implementação muda. Além disso, a camada imediatamente superior utilizará a interface para acesso aos dados e não a implementação. 129

6.1.4.4.3. CONSEQUÊNCIAS As conseqüências de utilizar o padrão DAO em um projeto são: • • • •

Transparência e independência na forma de persistência de dados; Facilidade de migração de um tipo de fonte de dados para outro (ex: MySQL para PostgreeSQL); Redução na complexidade da implementação das classes responsáveis pela lógica de negócio; Centralização das classes de acesso às fontes de dados em uma camada;

6.1.4.5. LAYER Propicia a estruturação de aplicações que podem ser decompostas em subsistemas, no qual cada um é um nível particular de abstração.

6.1.4.5.1. PROBLEMA Como desacoplar e propiciar uma estruturação em sistemas em que as características dominantes são um conjunto de problemas de diferentes níveis e contextos?

6.1.4.5.2. SOLUÇÃO Deve-se estruturar o sistema em um número apropriado de camadas, onde todos os componentes de uma camada estão em um mesmo nível de abstração. Além disso, uma camada deve acessar os serviços providos apenas pela camada imediatamente inferior e uma camada deve prover serviços para a camada imediatamente superior. Em geral, a decomposição do sistema é feita através de camadas e partições. Uma camada é um subsistema que é composto por subsistemas de menor nível de abstração, já a partição é um subsistema no mesmo nível de abstração de outros subsistemas dentro de uma mesma camada. Resumindo, as camadas são compostas por partições e as partições estão relacionadas a uma determinada camada. Uma observação 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. CONSEQUÊNCIAS As conseqüências de utilizar o padrão arquitetural “Layer” são: • • • • •

Possível reutilização das camadas; Suporte à padronização; As dependências não estão espalhadas pelo código de implementação; Facilidade de mudança; Menor eficiência;

6.2. METODOLOGIA Nesta seção são 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 código-livre para desenvolvedores de “software” na linguagem Java. O NetBeans oferece ao programador um conjunto de ferramentas e funcionalidades para o desenvolvimento de aplicações profissionais para Desktop, WEB, móveis e coorporativas. O NetBeans foi desenvolvido em Java, logo é multiplataforma e funciona em qualquer sistema operacional que tenha suporta à máquina virtual Java (JVM). A interface gráfica do NetBeans pode ser vista na Figura 6.7. Alguns dos principais recursos do NetBeans são: •

• •

• • • • • • •

Editor de código fonte integrado, rico em recursos para aplicações Web (Servlets e JSP, JSTL, JSF, EJB) e aplicações visuais com Swing, que é uma API (Interface de Programação de Aplicativos) Java para interfaces gráficas típicas de Desktop. Suporte a plataforma JEE (Java Enterprise Edition); Visualizador de classes integrado ao de interfaces, que gera automaticamente o código dos componentes de forma bem organizada e estruturada, facilitando assim a compreensão e legibilidade; “Plugins” para UML; Suporte a programas de controle de versão como o CVS; Ajuda local e “on-line”; Depuração completa de aplicações e componentes; Capacidade de auto-completar; Suporte a banco de dados. Suporte a diversos servidores WEB, “container” de “servlets” e servidores de aplicação; 131

Figura 6.7 - Interface gráfica 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 aplicações WEB , baseadas em páginas JSP, através de componentes gráficos de interface do usuário (GUI). Permite também conectar esses componentes próprios de forma ágil aos objetos de negócio. O surgimento do JSF veio da necessidade de permitir o desenvolvimento de páginas WEB de forma visual, ou seja, no esquema de “arrastar e soltar” os componentes na tela, que neste caso é uma página JSP. Apesar de o objetivo do JSF ser de possibilitar a construção páginas JSP a partir de componentes visuais, nada impede que o usuário construa manualmente as páginas, já que o JSF fornece um conjunto de componentes UI (“User Interface”) e “tags” que permitem o desenvolvimento das páginas JSF. O que as ferramentas visuais para JSF fazem é apenas automatizar o processo e gerar o código equivalente à configuração visual da página JSP desenhada pelo desenvolvedor. Algumas características do JSF são: • • • • • • •

Permite o desenvolvimento de UIs através de um conjunto de componentes UIs pré-definidos; Reutiliza componentes da página; Fornece um conjunto de “tags” JSP para acessar os componentes; Fornece separação lógica de funções que envolvem a construção de aplicações WEB; Associa os eventos do lado cliente com os manipuladores dos eventos do lado do servidor; Possui um conjunto padrão de componentes de interface de usuário que possibilitam validação padronizada; Suporte à internacionalização e acessibilidade; 132

• •

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

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

Figura 6.8 - Funcionamento de uma interface de usuário com o JSF.

A página JSP, “mypage.jsp”, é uma página JSF, ou seja, uma página JSP que inclui “tags” JSF. Ela expressa os componentes de interface do usuário através da utilização de “tags” JSF. O componente UI da aplicação WEB (representados por “myUI”) gerencia os objetos referenciados pela página JSP. Esses objetos podem ser: • • •

Componentes UI que são mapeados para “tags” na página JSP; Quaisquer receptores ouvintes de evento, validadores e conversores que são registrados em um determinado componente; Componentes JavaBeans que encapsulam dados e funcionalidades específicas da aplicação, 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 aplicação, através do uso de arquivos XML e anotações. Além disso, o Hibernate é um “software” de código livre, distribuído sobre a licença LGPL. A principal característica e funcionalidade do Hibernate é a transformação das classes Java para tabelas em um banco de dados. O mesmo gera as instruções SQL e deixa o desenvolvedor livre do trabalho manual de conversão dos dados, mantendo, dessa forma, o programa portável para qualquer SGBD baseado em SQL, mas causando uma pequena perda de desempenho observada pela aumento do tempo de execução. O HQL (Hibernate Query Language) é um dialeto SQL para comunicação com o Hibernate. Ela é uma poderosa linguagem de consulta, que se parece muito com o SQL. A principal diferença é que a HQL é totalmente orientada a objeto e inclui os paradigmas de herança, polimorfismo e encapsulamento. No Hibernate, é possível usar tanto SQL quanto HQL. 133

6.2.4. JFREECHART O JFreeChart é hoje provavelmente a biblioteca mais famosa do mundo Java para desenvolvimento de gráficos (JFREECHART, 2009). Além disso, o JFreeChart é um projeto de “software” livre, iniciado em 2000, e com ampla aceitação no mercado. O JFreeChart possui licença LGPL que permite a sua utilização em projetos de código-fechado. O JFreeChart além de ser livre, é bastante robusto e flexível. É possível utilizar a biblioteca para o desenho de diversos tipos de gráficos: pontos, financeiros, barra, “pizza”, 2D, 3D, dentre outros. Além disso, o mesmo gera arquivos no formato JPG, PNG, SVG, EPS e exibe em componentes “Swing”, que são os componentes gráficos típicos de “Desktop” do Java. Dois exemplos de gráficos produzidos pelo JFreeChart e apresentados em componentes “Swing” podem ser vistos na Figura 6.9.

Figura 6.9 - Exemplos de gráficos produzidos com o JFreeChart.

6.2.5. “JASPER REPORTS” E “IREPORT” O “JasperReports” (JASPERREPORTS, 2009) é uma biblioteca escrita em Java, de código-fonte livre, projetada para facilitar a tarefa de criar relatórios para aplicações, sejam elas em Desktop ou WEB. O “JasperReports” fornece uma API para facilitar o desenvolvimento de relatórios, mas ainda sim exige que o desenvolvedor conheça o formato XML utilizado pelo “JasperReports” para criar relatórios, o que consome muito de tempo de um usuário iniciante. O “iReport” é um programa de código-livre capaz de criar visualmente os mais complexos relatórios possíveis para aplicações Java, no formato da biblioteca “JasperReports”. Com a popularidade do “iReport”, a “JasperSoft” (empresa responsável pelo “JasperReports”) tornou esse ferramenta oficial para construção de relatórios para o “JasperReports”.

134

6.2.6. GLASSFISH O “Glashfish” (GLASSFISH, 2009) é um servidor de aplicações desenvolvido pela Sun Microsystems para a plataforma JEE. As principais características do Glassfish são: • •

•

• •

Implementa os mais novos recursos disponibilizados pela plataforma JEE 5, que ajudam a aumentar eficiência do desenvolvedor; Aumenta a produtividade do desenvolvedor com APIs JEE simplificadas e recursos de anotações, que reduzem a quantidade de código da aplicação a ser desenvolvida; Fornece uma arquitetura aberta e extensível para colaboração entre tecnologia de integração e serviços WEB em uma arquitetura orientada a serviços (SOA). Servidor de aplicações padrão utilizada pela ferramenta NetBeans IDE; Possui código-livre;

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

Figura 6.10 - Logo do servidor de aplicações Glassfish.

6.3. ESPECIFICAÇÃO Nessa seção são apresentados alguns diagramas UML 2.0 que descrevem as características, requisitos e arquitetura do sistema WEB desenvolvido para o monitoramento de temperatura. Os diagramas UML utilizados são: diagrama de casos de uso e diagramas de classe. A arquitetura do sistema é apresentada de forma incremental, através de três diagramas de classe: arquitetura em três camadas com a notação MVC, arquitetura refinada com padrões 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 usuário Administrador, já que o sistema foi idealizado para ser utilizado como um sistema de administração e monitoramento apenas. Além disso, esse sistema WEB deve ser capaz de fornecer um meio para que seus próprios serviços sejam configurados, bem como o comportamento/funcionamento do “JDaemon” (Capítulo 5). Para ter acesso às funcionalidades do sistema, deve-se primeiro realizar o processo de autenticação no mesmo. O ator Administrador pode, através do caso de uso “Administrador Sistema WEB”, executar os casos de uso “cadastrar um novo administrador”, “alterar administrador”, “remover administrador” ou “listar administradores”. Além disso, ele também pode, através do caso de uso “Configurar Serviços”, executar os casos de uso “Configurar Sistema WEB” e “Configurar Daemon”, responsáveis respectivamente pela configuração do sistema WEB e do “Daemon” para aquisição remota de temperatura. Por fim, a principal funcionalidade do sistema é utilizada através da execução do caso de uso “Verificar relatórios de temperatura”, que executa obrigatoriamente os casos de uso “Verificar alarmes de temperatura” e “Verificar gráficos de temperatura”. Esses dois últimos casos de uso podem ser executados individualmente, caso o usuário administrador queira apenas obter informações sobre os alarmes ou verificar a dinâmica da temperatura através dos gráficos. O caso de uso “Verificar relatório de temperatura” apresenta um relatório completo, ou seja, com as informações de alarme e os gráficos.

136

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

6.3.2. DIAGRAMA DE CLASSE: ARQUITETURA EM TRÊS CAMADAS Na Figura 6.12 é apresentada de forma resumida a arquitetura em três camadas do sistema. Essa não foi a arquitetura utilizada para implementação, mas serviu como base para definição das camadas e para possibilitar uma maior facilidade na aplicação dos padrões de projeto e utilização das tecnologias (JSF e Hibernate). Essa arquitetura divide o sistema nas camadas: apresentação, negócio e dados. Sendo que a nomenclatura utilizada para defini-las foi a do MVC. Além disso, pode-se dizer que essa arquitetura utiliza o padrão “layer”, pois a mesma permite comunicação apenas no sentido da camada superior para a imediatamente inferior e organiza o sistema em camadas e partições. As camadas utilizadas (visão, negócio e dados) podem ser observadas na Figura 6.12. Já as partições são os componentes de uma determinada camada, a saber: Camada de visão – PagCadastroPessoa, PagVerGrafico, PagVerRelatório, dentre outros; Camada de negócio – ControladorPessoa, ControladorRelatorio, ControladorGrafico, dentre outros; Camada de dados – Pessoa, Grafico, Relatorio, dentre outros. As classes relacionadas às camadas (Visão, Controle e Modelo) podem ser identificadas, respectivamente, através dos estereótipos “Boundary”, “Control” e “Entity”. O estereótipo “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 partições. Além disso, através da construção da mesma, o processo de aplicar padrões de projeto no sistema foi bastante facilitado.

Figura 6.12 - Arquitetura em três camadas utilizando a nomenclatura MVC.

6.3.3. DIAGRAMA DE CLASSE: ARQUITETURA REFINADA COM PADRÕES DE PROJETO Apesar de a arquitetura da seção 6.3.2 já fornecer uma boa estruturação para a implementação, ainda sim é possível aplicar padrões de projeto, a fim de introduzir algumas melhorias e aumentar a reutilização. Na Figura 6.13 pode ser visto a arquitetura em três camadas refinada com padrões de projeto. A camada de GUI (ou visão) é composto por um único “servlet”, um conjunto de páginas JSP e comandos. Os comandos são classes que utilizam o padrão “command” para encapsular, através de um objeto, a requisição do usuário por uma funcionalidade do sistema. Um único “servlet” foi utilizado para facilitar a manutenção e aumentar o desempenho da aplicação. O “servlet” é um componente “multithread”, logo apenas um pode atender às várias requisições de forma concorrente. Um inconveniente na utilização do “servlet” é que cada requisição/resposta gerada pelo sistema WEB deve ser tratada pelo “servlet”. Na prática, 138

significa que toda vez que o “servlet” receber uma requisição, ele deve inicialmente identificar, através de uma estrutura condicional (“IF”), o que está sendo solicitado ou submetido e em seguida deve fazer o tratamento adequado. Em geral, cada formulário de sistema WEB introduziria uma verificação condicional no “servlet” e seu respectivo código de tratamento. Logo, se o sistema possuir, por exemplo, 400 formulários, o processo fica bastante inviável e de manutenção difícil. O padrão “command” resolve esse problema, utilizando uma estrutura de dados chamada “hashtable”, que armazena objetos comando associando-os a “chaves”. Através dessas chaves pode-se recuperar um determinado comando específico. Além disso, é criada uma classe abstrata chamada “ComandoGenerico”, com um único método abstrato, que deve ser implementado por todas as classes que estendem a mesma. Então, é criada para cada possível requisição um comando que estende a classe “ComandoGenerico” e implementa o método abstrato com o respectivo tratamento que se deseja para essa requisição. Posteriormente, no “servlet” são criados todos os objetos comandos utilizados pelo sistema e inseridos na “hashtable” com uma “chave” que identifica a funcionalidade desse comando. Assim, quando uma requisição/solicitação é recebida pelo “servlet”, o mesmo procura na “hashtable” o comando adequado para tratá-la e o executa. Dessa forma, não é mais necessária nenhuma verificação condicional e implementação do tratamento da requisição dentro do próprio “servlet”: o padrão “command” se encarrega de identificar a requisição e executar o comando especifico, ou seja, o padrão faz basicamente um “roteamento” entre o serviço solicitado e sua implementação. Adicionar novos comandos é muito simples, basicamente deve-se implementar o comando desejado e inserir na “hashtable”, introduzindo apenas uma linha de código no “servlet” ao invés de dezenas como era esperado anteriormente. Outro problema com a arquitetura da seção 6.3.2 é que há um acoplamento muito forte entre as camadas de visão e negócio. Além disso, cada página da visão deve conhecer o controlador associado, tornando o acesso a funcionalidades e serviços bastante desestruturado e espalhado. Para resolver esse problema, foi utilizado o padrão “facade”, que introduz uma interface com todos os serviços providos pela camada negócio, centralizando e estruturando melhor esse acesso. Logo, as classes de visão apenas precisam conhecer a fachada e não quem são os responsáveis pela implementação do serviço, ou seja, os controladores. Na implementação da fachada são programados todos os serviços providos pela sua interface. Esses serviços são basicamente implementados através de chamadas (execuções) dos controladores para cada serviço específico. Além de implementar o padrão “facade”, a fachada também implementa o padrão “singleton”, que garante que haja apenas uma instância do objeto fachada no sistema, evitando assim que existam várias fachadas que provêem o mesmo serviço. Os controladores possuem o mesmo objetivo que possuíam na arquitetura 6.3.2, ou seja, são responsáveis pelas lógicas de negócio. Mas há um problema na arquitetura 6.3.2, que é o acoplamento da lógica de negócio com a lógica de persistência. Ou seja, nos controladores ou modelos também há códigos de persistência. Para resolver esse problema, foi utilizado o padrão “DAO”, o padrão cria uma interface que é acessada pelos controladores. Dessa forma, o código de persistência está armazenado na implementação dessa interface DAO e não nos controladores. Logo, se a tecnologia de persistência for alterada, as classes de negócio permanecerão praticamente intactas, pois utilizam a interface e não a implementação, aumentando assim o reuso e manutenção do sistema.

139

Figura 6.13 - Arquitetura em três camadas refinada com padrões de projeto.

140

6.3.4. DIAGRAMA DE CLASSE: ARQUITETURA COM AS TECNOLOGIAS JSF E HIBERNATE A arquitetura descrita nessa seção 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 relação à arquitetura do sistema, é que o mesmo já implementa o padrão “command”. Dessa forma, as páginas JSP produzidas com JSF já possuem capacidade de “rotear” a solicitação para o serviço específico, 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 implementação. O mesmo é capaz de fazer a tradução objeto-relacional automaticamente, o que é muito importante se o sistema é orientado a objetos e utiliza uma SGBD relacional. Além disso, o “Hibernate” possibilita a geração 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” também possui “drivers” para maioria dos SGBD e possibilita que o sistema possa trocar de tecnologia de persistência, alterando apenas uma linha no arquivo de configuração, que é responsável por indicar qual o SGBD está sendo utilizado. Em geral, quando apenas o padrão DAO é utilizado, se a tecnologia de persistência é alterada, uma nova implementação dos DAO também se faz necessária. Já quando o sistema utiliza o “Hibernate”, os DAOs não precisam ser rescritos, já que a manipulação do banco de dados é provida através de uma interface comum para os SGBD. A utilização de “frameworks” como “Hibernate” e JSF diminuem o acoplamento entre os subsistemas da aplicação, aumentam o reuso e produtividade, já que muitas classes são abstraídas pelos próprios “frameworks” e não precisam ser implementas pelo usuário.

141

Figura 6.14 - Arquitetura com as tecnologias JSF e Hibernate.

142

7. TESTES E RESULTADOS Neste capítulo são apresentados os resultados de alguns testes realizados, com o objetivo de verificar alguns parâmetros de desempenho, relacionados ao circuito microcontrolado para monitoramento de temperatura e disponibilização dos dados via Internet. Os testes foram realizados utilizando as simulações dos circuitos e os respectivos programas embarcados descritos no capítulo 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. Através do mesmo foi testado o tempo de resposta do circuito utilizando os dois programas embarcados. Além disso, o servidor HTTP foi testado em três cenários específicos. Os testes foram muito interessantes, pois ficou muito evidente a influência de cada programa e cenário no tempo de resposta do circuito quando conectado em rede. Mas a análise dos testes não foi simples, pois como o circuito é simulado em computador, diversos fatores e variáveis aleatórias podem influenciar de forma positiva ou negativa no desempenho do circuito, como: programas em execução, “download” e “upload” em curso, dentre outros. Além desses fatores, também influenciam no resultado da simulação: o “hardware” do computador no qual o simulador é executado e a qualidade do enlace da rede. Mas, esses fatores foram abstraídos e as justificativas de desempenho foram baseadas apenas nos fatores relacionadas ao circuito e seus programas embarcados. Para realização dos testes foi utilizado um computador cujos componentes de “hardware” de interesse são: processador Athlon XP 2600+ (1.91GHz), 2GB de memória 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 retângulo na Figura 7.1 fazem parte do mesmo dispositivo físico, que é um computador do tipo PC. Quando a simulação 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 execução de três comandos “ping” seqüenciais, 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 não foram utilizados para o cálculo da média 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 estratégia cooperativa multitarefa, na qual cada tarefa têm 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 ausência de tempo de resposta no gráfico. O “pico” ocorre quando uma tarefa demora muito mais que as demais e a ausência de tempo de resposta ocorre quando não houve uma resposta antes do “time out” do comando “ping”.

Figura 7.1 - Ambiente montado para testes de desempenho.

O cenário lógico para realização dos testes pode ser visto na Figura 7.2. Ele consiste no uso do Proteus VSM para simulação do circuito e do terminal de comandos do Microsoft Windows XP para executar o comando “ping”.

Figura 7.2 - Cenário lógico para os testes de desempenho.

144

7.1. SERVIDOR HTTP MICROCONTROLADO O servidor HTTP microcontrolado foi testado em três cenários específicos: • •

•

Enviando a página HTML armazenada no mesmo; Utilizando apenas requisições AJAX assíncronas, para atualizar o valor de temperatura na página HTML. Essa situação ocorre quando todo conteúdo estático (“layout”) foi carregado e apenas o conteúdo dinâmico (valor da temperatura) é atualizado; Com servidor HTTP inativo. Essa situação ocorre quando não há nenhum tipo de requisição HTTP sendo respondida pelo servidor e o mesmo passa a responder apenas ao comando “ping”.

Os resultados dos testes nesses três cenários são apresentados nas seções 7.1.1, 7.1.2 e 7.1.3.

7.1.1. SERVIDOR HTTP MICROCONTROLADO ENVIANDO UMA PÁGINA HTML O gráfico que apresenta o resultado dos testes nesse cenário pode ser visto na Figura 7.3. A média das três execuções dos comandos “ping” são respectivamente 640, 822 e 833 ms. Conforme o mencionado anteriormente, utilizou-se três comandos “ping”, onde cada um realizou dez amostras de conectividade e tempo de resposta. As três seqüencias de comandos “ping” podem ser identificados da seguinte forma: primeira seqüência – comandos de número 1 a 10; segunda seqüência – comandos de número 11 a 20; terceira seqüência – comandos de número 21 a 30. Percebe-se que a primeira execução teve um tempo médio de resposta menor que as outras, provavelmente porque o comando foi executado nos instantes iniciais ou finais do processamento de resposta da requisição pela página HTML. Observando a Figura 7.3 percebe-se que pelo menos um dos três primeiros comandos de cada seqüência ultrapassam a média do tempo de resposta e também são superiores a 1000 ms. Isso ocorre porque esses comandos são executados durante o inicio do processo de resposta da requisição HTTP pela página HTML. Nessa etapa são enviados para o navegador WEB do cliente as figuras, textos e demais componentes HTML. Além disso, os últimos comandos de cada seqüência (10, 21 e 30) sempre estão abaixo da média do tempo de resposta e também são inferiores a 500 ms, já que nessa situação grande parte do conteúdo da página HTML já foi enviado para o navegador WEB do cliente.

145

Figura 7.3 - Desempenho do servidor HTTP microcontrolado servindo uma página HTML.

7.1.2. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS A REQUISIÇÕES ASSÍNCRONAS AJAX O gráfico que apresenta o resultado dos testes nesse cenário pode ser visto na Figura 7.4. A média dos testes das três seqüências de comandos “ping” foram 418, 456 e 459 ms. Percebe-se que o tempo de resposta nessas condições foi menor do que quando o circuito microcontrolado está enviando a página HTML. O que faz bastante sentido, já que as requisições assíncronas 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 requisições AJAX 146

Observando a Figura 7.4, percebe-se que, neste cenário, o tempo de reposta é mais determinístico do que no cenário da seção 7.1.1. Isso ocorre porque apenas um pequeno conjunto de requisições bastante similares é gerado. Essas requisições são relativas ao valor de temperatura atual, já as da seção 7.1.1 são relativas a figuras, textos, tabelas, dentre outros, que certamente necessitam de tempos distintos para serem completamente enviados ao cliente. Além disso, o trigésimo comando “ping” não teve sua requisição respondida a tempo, o que pode ser verificado pela ausência do tempo de resposta no gráfico.

7.1.3. SERVIDOR HTTP MICROCONTROLADO RESPONDENDO APENAS AO “PING” O gráfico que apresenta os dados desse teste pode ser visto na Figura 7.5. A média dos testes das três seqüencias de comandos “ping” foram 106, 57 e 114 ms. O segundo teve em média um tempo de resposta menor provavelmente porque imediatamente antes de cada “ping”, o fluxo de execução do programa embarcado estava o mais próximo possível do momento em que o “StackManager” estava para ser executado e pronto para verificar se havia alguma requisição que deveria ser respondida. Assim, ele pôde perceber a requisição 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 equilíbrio, ou seja, algumas chamadas ao “StackManager” são muito antes, outras depois e algumas um pouco antes. Logo, quando se faz a média, 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 execução do “StackManager”.

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

147

Percebe-se também que o tempo de resposta nesse cenário foi bem menor do que os obtidos nas duas seções anteriores. Isso faz bastante sentido, já que nesta situação o servidor não estava respondendo uma requisição pela página HTML e nem respondendo requisições assíncronas AJAX. Logo, apenas o servidor ICMP, que é o responsável por responder ao comando “ping” estava como serviço de rede “ativo” no momento. Além disso, pode-se perceber, pelo tempo de resposta do vigésimo primeiro “ping”, que alguma das tarefas demorou mais que o normal. Essa tarefa poderia ser, por exemplo, o processo de conversão 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 média dos três testes foram respectivamente 14, 11 e 12 ms. Percebe-se que os tempos de execução foram bastante inferiores aos obtidos nas seções anteriores. Isso ocorreu porque não está sendo utilizado nenhum serviço da camada de aplicação da pilha TCP/IP, como por exemplo, o HTTP, que foi utilizado nos testes da seção 7.1. Geralmente, são esses serviços 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 cenários 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 seção 7.1.3, pois em ambos os casos não está sendo utilizado um serviço da camada de aplicação no momento dos testes. Mas há um detalhe importante, no teste da seção 7.1.3, o servidor HTTP não está ativo, mas está habilitado. Já no teste da seção corrente, o servidor HTTP não está habilitado. Então, o gerenciador do servidor HTTP não utiliza nenhum ciclo de máquina para verificar se há alguma requisição que deve ser respondida. Já na situação apresentada na seção 7.1.3, o gerenciador do servidor HTTP está continuamente fazendo essa operação.

149

8. CONCLUSÕES A Internet embarcada se revela como uma tendência 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, soluções de monitoramento ou acionamento remoto via Internet possam ser implementadas, utilizando apenas uma placa ao invés de um computador, diminuindo assim o custo da implantação do serviço. No contexto do PoP-RN, o sistema de monitoramento de temperatura proposto contribuirá, em um futuro próximo, para a manutenção da infra-estrutura instalada e possibilitará com que análise de tráfego, 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, não havia no mercado uma plataforma nacional para o desenvolvimento de soluções utilizando Internet embarcada. Em pouco mais de um ano, as plataformas apresentadas no capítulo 2 foram desenvolvidas e passaram a ser comercializadas. Isso evidencia a importância 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 propósito geral que possui conectividade Ethernet, mas agrega vários recursos que não seriam aproveitados a princípio no sistema proposto, e por isso uma plataforma alternativa foi projetada. Assim como a PICDEM.net 2, as demais plataformas apresentadas no capítulo 2 também são de propósitos gerais e dispõem de alguns componentes e características que não são de interesse, como: conexão USB, leitor de cartão 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 então 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 difícil concluir, em curto prazo, o desenvolvimento de um “hardware” complexo como o proposto neste trabalho, pois não há no mercado local empresas que comercializem todos componentes necessários. Fez-se necessário, então, através da Internet e telefone entrar em contato com empresas de outros estados e países, o que se mostrou uma solução improdutiva e de longo prazo. Assim, como houve um gasto demasiado de tempo com a atividade anterior e também 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 necessários: cliente TCP e servidor HTTP microcontrolados, “daemon” para aquisição remota de temperatura via Internet e sistema WEB para monitoramento de temperatura. Em virtude dos problemas para aquisição 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 através do mesmo esses programas, bem como a plataforma 150

proposta, foram testados e validados. Nessa circunstância, 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 relação aos dois programas embarcados, a Microchip teve uma iniciativa muito nobre, ao disponibilizar uma pilha TCP/IP e ferramentas relacionadas de forma gratuita para utilização com microcontroladores e DSPs, o que certamente contribuiu e ainda contribuirá para a popularização da tecnologia Internet embarcada. Além disso, a Microchip também disponibiliza gratuitamente uma biblioteca de funções utilitárias baseadas no compilador C18, para uso com microcontroladores da família PIC 18F. Por meio dessas duas iniciativas, “software” complexos como o servidor HTTP e cliente TCP para microcontroladores puderam ser implementados, estes programas são constituídos de um conjunto de aproximadamente 60 arquivos em linguagem C e permitem que um “chip” (microcontrolador) se conecte à Internet, atuando como um servidor de páginas HTML ou um cliente TCP para estabelecimento de conexão remota via “socket”. O AJAX, apesar de ser uma tecnologia comumente utilizada apenas para promover melhorias na apresentação e interação de sistemas WEB com os usuários, 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 política cooperativa multitarefa se mostrou bastante satisfatória e conveniente para implementação de serviços complexos (ex: pilha TCP/IP) em sistemas microcontrolados, evitando inclusive a necessidade se utilizar um RTOS. O padrão “Berkeley Sockets” para comunicação em rede utilizando TCP e UDP é um grande exemplo da importância de padronização de “software”, pois através dessa API, um microcontrolador pôde comunicar-se e enviar dados para um computador do tipo PC, sem haver problemas de codificação e ordenação dos bytes (ex: “Big Endian” ou “LittleEndian”), que é muito comum quando sistemas utilizam processadores diferentes, como neste caso. Em relação ao “daemon” para aquisição remota de temperatura, estudos sobre programação concorrente (“threads”, processos, comunicação interprocessos e exclusão mútua) e seus mecanismos de suporte (“mutex”, monitores, semáforos, troca de mensagens) foram muito importantes para implementação do mesmo. A utilização de um sistema baseado em Unix também foi relevante, já que através do mesmo foi possível utilizar recursos nativos Unix (“signal” e “alarm”) e POSIX (“threads” e “mutex”). A especificação em UML foi importante não só como referência para implementação, mas também como documentação para futuras evoluções do “daemon” implementado. O Eclipse CDT se mostrou uma ferramenta muito produtiva para programação em C/C++, pois utiliza de forma integrada o utilitário “make”, que facilita bastante a compilação de um projeto que utiliza muitos arquivos e bibliotecas. Além disso, o mesmo identifica erros de sintaxe e os apresenta de forma visual (sublinhando a linha), o que facilitou a percepção dos mesmos, poupando tempo. O SGBD MySQL é realmente de fácil utilização e fornece uma API para utilização com a linguagem de programação C, que se mostrou muito simples e robusta. O MTA “Postfix” cumpriu muito bem o seu papel no desenvolvimento do “daemon”, pois sua instalação e utilização foram bastante simples. Além disso, o mesmo apresentou um desempenho melhor que o “sendmail”, que havia sido testado anteriormente. Um ponto importante e de dificuldade em relação ao “daemon”, foi o encapsulamento de recursos de baixo nível em C para classes C++, o que gerou muitos problemas e, conseqüentemente, utilizou uma razoável quantidade de tempo. Então, se uma implementação em C utilizando recursos de baixo nível for necessária, um caminho mais 151

conveniente pareceu ser manter a implementação totalmente estruturada, ao invés de introduzir orientação a objetos. Também pareceu bastante conveniente evitar a utilização de recursos concorrentes da linguagem C em classes C++, pois como mencionado no capítulo 5, não se conseguiu abrir um arquivo de forma satisfatória utilizando a biblioteca para manipulação de “Stream” do C++ no interior de um “thread” padrão POSIX. Uma possibilidade futura e alternativa para o “daemon”, caso seja difícil adicionar novos recursos ao mesmo, seria reprogramá-lo utilizando a linguagem “Java”, pois o Java disponibiliza APIs já orientadas a objetos, que facilitam a reutilização 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 execução por uma máquina virtual. Já um código em C/C+ é compilado e executado, utilizando a linguagem de máquina nativa da plataforma em questão. Por isso, a C/C++ foi a linguagem de programação escolhida. Em relação ao sistema WEB, a plataforma JEE se mostrou bastante estável e produtiva para o desenvolvimento de sistemas WEB, pois os componentes providos pela mesma, como: “Servlets”, “JSP”, “JSTL” e “JSF”, são de simples utilização. O servidor de aplicações “Glassfish” se mostrou bastante eficiente e confiável para execução de componentes JEE. Provavelmente, por esse motivo, o mesmo é o servidor de aplicações atualmente recomendado pela Sun. Além disso, a grande vantagem de utilizar a tecnologia Java, além da portabilidade, é o grande fluxo de novidades e APIs implementadas (ex: “Jasper Reports” – para relatórios; “JFreechart” – para gráficos), que cada vez mais facilitam o desenvolvimento de sistemas, sejam eles móveis, “desktop” ou WEB. A arquitetura MVC e em três camadas foi bastante importante para uma estruturação inicial da aplicação e separação das classes de acordo com sua funcionalidade no escopo do sistema, além de facilitar futuras migrações na tecnologia de apresentação e persistência. Dessa forma, o sistema aqui proposto estará apto a mudar para tecnologias alternativas, se necessário, preservando grande parte da sua lógica de negócio, que é o que na verdade caracteriza o sistema. A aplicação dos padrões de projeto contribuiu ainda mais para a estruturação das camadas e para aumentar o reuso e flexibilidade da arquitetura, facilitando com que tecnologias como JSF e Hibernate, pudessem ser adicionadas de forma satisfatória sem comprometer a arquitetura elaborada. Além disso, ter uma arquitetura alternativa, especificada apenas com padrões de projeto, é importante para que o sistema não fique 100% depende de tecnologias. A espeficicação UML foi importante para o levantamento de requisitos do sistema e para definição da arquitetura a ser utilizada. Essa especificação pode servir como base para a implementação de novos casos de uso e funcionalidades. Em relação 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. Além disso, o cenário de teste mais favorável (respondendo apenas ao comando “ping”) no qual o servidor HTTP microcontrolado foi testado teve o melhor desempenho dentre os três cenários analisados. Uma dúvida que pode ter permanecido até o presente momento, seria porque armazenar a temperatura utilizando uma variável inteira e não 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 (Seção 3.1.2), o mesmo não tem unidade especifica para tratamento de números em ponto-flutuante. Além disso, para apresentação de um dado no “display LCD”, o mesmo deve ser convertido para o tipo “string”. A biblioteca C18 não dispõe de uma função 152

para essa conversão. Mas a mesma foi implementada e verificou-se que utilizava muitos ciclos de máquina e muita memória de programa, sendo provavelmente por esse motivo que a Microchip não incluiu uma função similar na biblioteca C18. Levando em consideração a experiência obtida durante o desenvolvimento deste trabalho, percebeu-se que se a intenção real de um projeto é a implementação de um serviço que necessite de um “hardware” complexo, como o aqui apresentado, o mais indicado seria adquirir uma plataforma comercial, e a partir dela realizar a implantação do serviço desejado. Posteriormente, já com o serviço 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 viável as necessidades do serviço considerado. Se pudesse ter sido adquirida no início do projeto uma plataforma com Internet embarcada, possivelmente hoje o serviço poderia estar em funcionamento ou em fase de implantação. Entretanto, é importante que todos os estudos, “software” e sistemas desenvolvidos sejam válidos, pois uma solução alternativa ao desenvolvimento de um “hardware” dedicado seria realizar a compra de uma das plataformas nacionais apresentadas no Capítulo 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 versão similar, disponível para venda no mercado, evidenciando assim sua importância, já que são programas que foram desenvolvidos para solucionar um problema específico. Além disso, a implementação dos programas embarcados nestas plataformas não deve ser muito complexa, pois todas as plataformas apresentadas utilizam a solução para Internet embarcada da Microchip, assim como a plataforma proposta neste trabalho. Além disso, uma das grandes dificuldades na utilização da pilha TCP/IP embarcada consiste na configuração da mesma para executar em uma plataforma específica. Entretanto, todas as plataformas com Internet embarcada baseadas na pilha TCP/IP da Microchip já possuem pelo menos um exemplo de aplicação para testes de conexão Ethernet/Internet. Logo, estas configurações podem ser observadas e utilizadas por qualquer “software” embarcado, que venha a utilizar a pilha TCP/IP nestas plataformas. O trabalho aqui apresentado não deveria servir apenas como documentação de uma proposta de projeto, cujo objetivo era solucionar um problema específico. Mas deve ser visto também como um documento que apresenta uma tecnologia que certamente influenciará na área de redes de computadores e sistemas embarcados, pois em um futuro próximo, muitos dispositivos se conectarão à Internet e certamente eles terão um microcontrolador (ou similar), um controlador de rede (Ethernet, Wi-Fi, Bluetooth, dentre outros) e uma pilha TCP/IP embarcada. Em relação ao estágio 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 não fosse através do PoP-RN e das pessoas altamente competentes, que fazem com que o mesmo seja uma instituição de referência da RNP. Tenho muito orgulho de um dia ter sido parte dessa equipe. Sou muito grato por todo conhecimento e experiência profissional adquiridos e espero ter conseguido retribuir à altura, através de minhas atividades como bolsista/estagiário.

153

REFERÊNCIAS BIBLIOGRÁFICAS (ANDERSON,1999) – Multitasking http://cse.stanford.edu/class/cs110/handouts/32Multitasking.pdf. - . (BALAZS,2009) – A Practical Use of the MVC Pattern http://www.codeproject.com/KB/architecture/PraticalMvc.aspx - . (BARNEY,2009) – POSIX Threads Programming - https://computing.llnl.gov/tutorials/pthreads/  - . (DEBIAN,2009) – Debian GNU/LINUX - http://www.debian.org/- . (DE SOUZA,2003A) - Desbravando o PIC - Ampliado e Atualizado para PIC 16F628A, 1ª Edição, Editora Érica, 2003. (DE SOUZA,2003B) - Conectando o PIC: Recursos Avançados A vançados , 2ª Edição, Editora Érica, 2003. (ECLIPSE, 2009) – Eclipse IDE - http://www.eclipse.org . (EXSTO,2009A) - Exsto - http://www.exsto.com.br - . (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 - . (GAMMA ;HELM; JOHNSON; VLISSIDES, 1994) – Design Patterns: Elements of Reusable Object-Oriented Software, E. Gamma, R. Helm, R. Johnson, J. Vlissides. 1ª Edição, Editora Bookman. (GLASSFISH, 2009) – Glassfish Open Source Application Server - https://glassfish.dev.java.net/  - . (GUEDES, 2008) – UML: uma abordagem prática, G. Guedes, 3ª Edição, Editora Novatec. (HEIDRICH,2009) – Programação Concorrente: Threads http://www.inf.unisinos.br/~barbosa/grefe/atividades/at3/leonardo_3.pdf - . (JASPERREPORTS,2009) – Jasper Reports Library - http://jasperforge.org - (JAVA, 2009) – Developer Resources for Java Ja va Technology - http://java.sun.com/ - . (JAVAEE,2009A) – Java Platform, Enterprise Edition - http://java.sun.com/javaee/- . (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 - . 154

(JHD204,2005) – Display LCD JHD204 http://www.egochina.net.cn/eshop/ebay/catalog/JHD204A.pdf - . (JFREECHART, 2009) – JFreechart Libray - http://www.jfree.org/jfreechart/ - . (JUDE, 2009) – JUDE/Professional - Design & Modeling - http://jude.change-vision.com/judeweb/index.html - . (LABTOOLS,2008A) – LabTools - http://www.labtools.com.br/index - . (LABTOOLS,2008B) – Explorer16BR PIC24FJ128GA010-I/PT http://www.labtools.com.br/index.asp?area=21&subarea=b&idioma=por&script=produtos&prod =1054 - . (LABCENTER,2008) – Proteus VSM - http://www.labcenter.co.uk/products/vsm_overview.cfm - . (LINUX-TUTORIAL,2009) – The Life Cycle of Processes - http://www.linuxtutorial.info/modules.php?name=MContent&pageid=84 - . (MATTHEW; STONES,2007) – Beginnig Linux Programming, N. Matthew, R. Stones, 4ª Edição, Editora Wrox. (MELO; NASCIMENTO,2008) – PHP Profissional: aprenda a desenvolver sistemas profissionais orientados a objetos com padrões de projeto, A. Melo, M. Nascimento, 1ª Edição, Editora Novatec. (MICROCHIP,2007) PICDEM.net2 Development Board http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocNa me=en028217 - . (MICROCHIP,2008A) - Microchip Technology Inc. The Embedded Control Solutions Company® - http://www.microchip.com . (MICROCHIP,2008B) – Microchip ENC28J60 Data Sheet http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf - . (MICROCHIP,2008C) – Microchip PIC18F2525/2620/4525/4620 Data Sheet – http://ww1.microchip.com/downloads/en/DeviceDoc/39626e.pdf - . (MICROCHIP,2008D) – Microchip: TCP/IP download and support http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2505¶m= en535724 - . (MICROCHIP,2008E) – Microchip TCP/IP Stack Application Note http://ww1.microchip.com/downloads/en/AppNotes/00833c.pdf - . (MICROCHIP,2008F) – MPLAB Integrated Development Environment http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_User_Guide_51519c.pdf .

-

(MICROCHIP,2008G) – MPLAB C Compiler for PIC18 MCUs http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_C18_Libraries_51297f.pdf .

155

(MICROGENIUS,2008A) - Microgenius - http://www.microgenius.com.br- . (MICROGENIUS,2008B) MagicPIC board http://www.microgenius.com.br/shop/detalhes.asp?id=28&produto=557 - . (MYSQL,2009) - Manual de Referência do MYSQL – versão 4.1 http://dev.mysql.com/doc/refman/4.1/pt/index.html .

-

(NATIONAL SEMICONDUCTOR, 1994) - LM35/LM35A/LM35C/LM35CA/LM35D: Precision Centigrade Temperature Sensors http://www.datasheetcatalog.org/datasheet/nationalsemiconductor/DS005516.PDF - . (NETBEANS,2009) - http://www.netbeans.org - . (NIEDERAUER,2007) – Web Interativa com Ajax e PHP, J. Niederauer, 1ª Edição, Editora Novatec. (NETO; NADALETE; GENNARI; FREITAS,2009) – Desenvolvimento de Sistema Web utilizando arquitetura em Três Camadas e Applets http://inf.unisul.br/~ines/workcomp/cd/pdfs/2905.pdf - . (PEREIRA,2003) - Microcontroladores PIC – Programação em C, 4ª E dição, Editora Érica. (POSTFIX,2009) – MTA Postfix - http://www.postfix.org - . (SAMSUNG,2000) – Controlador LCD S6A0069 - http://www.egochina.net.cn/eshop/eBay/Datasheet/s6a0069.pdf - . (SANTOS; FIALHO,2008A) – SAGA: Um Sistema WEB para Administração e Gerenciamento de servidores VoIP baseados no Asterisk PBX – Relatório técnico PoP-RN – Johnny C. Marçal dos Santos; Sergio V. Fialho. (SANTOS; FIALHO,2008B) – WEBSec: Um módulo de segurança para prevenção, detecção e auditoria de ataques WEB – Relatório técnico PoP-RN – Johnny C. Marçal dos Santos; Sergio V. Fialho. (SEIXAS FILHO; SZUSTER, 2002) – Programação Concorrente em Ambiente Windows: uma visão de automação – Constantino Seixas Filho; Marcelo Szuster, 1ª Edição, E ditora UFMG. (SMITH,2005) – Microchip's ENC28J60, World's Smallest Ethernet Controller – Seminário WEB Nate Smith http://techtrain.microchip.com/webseminars/ArchivedDetail.aspx?Active=94 - . (SILBERSCHATZ; GALVIN; GAGNE,2007) – Sistemas Operacionais com Java, A. Silberschatz; P. Galvin; G. Gagne, 7ª Edição, Editora Elsevier. (SUN,2009) – Sun Microsystems - http://www.sun.com/- . (TANENBAUM,2007) – Sistemas Operacionais Modernos, A. Tanenbaum, 7ª Edição, Editora Prentice Hall. (UML, 2009) – Unified Modeling Language - http://www.uml.org//- . 156