UNIVERSIDADE FEDERAL DE OURO PRETO

ESCOLA DE MINAS
COLEGIADO DO CURSO DE ENGENHARIA DE
CONTROLE E AUTOMAO - CECAU







PEDRO HENRIQUE SOUSA PRADO










CONTROLE E MONITORAMENTO DA TEMPERATURA DE UM AMBIENTE
UTILIZANDO UM CONJUNTO MICROCONTROLADOR/PC









MONOGRAFIA DE GRADUAO EM ENGENHARIA DE CONTROLE E
AUTOMAO













Ouro Preto, 2011


PEDRO HENRIQUE SOUSA PRADO









CONTROLE E MONITORAMENTO DA TEMPERATURA DE UM AMBIENTE
UTILIZANDO UM CONJUNTO MICROCONTROLADOR/PC







Monografia apresentada ao Curso de
Engenharia de Controle e Automao
da Universidade Federal de Ouro Preto
como parte dos requisitos para a
obteno do Grau de Engenheiro de
Controle e Automao.








Orientador: Henor Artur de Souza










Ouro Preto
Escola de Minas UFOP
Dezembro/2011


















Fonte de catalogao: bibem@sisbin.ufop.br


P896c Prado, Pedro Henrique Sousa.
Controle e monitoramento da temperatura de um ambiente utilizando
um conjunto microcontrolador/pc. [manuscrito] / Pedro Henrique
Sousa Prado. 2011.
87f. : il., color., graf., tab.

Orientador: Prof. Dr. Henor Artur de Souza.

. Monografia (Graduao) Universidade Federal de Ouro
Preto. Escola de Minas. Colegiado do Curso de Engenharia de Controle
e Automao.
rea de concentrao: Engenharia de Controle e Automao.

1. Automao industrial. 2. Sistemas difusos. 3. Controle automtico.
4. Conforto trmico. I. Universidade Federal de Ouro Preto. II. Ttulo.


CDU: 681.5

























SUMRIO
1- INTRODUO 8
1.1- Descrio do problema 10
1.2- Objetivo 11
1.3- Metodologia 11
1.4- Estrutura do trabalho 11
2- SISTEMAS DE CONTROLE 13
2.1- Histrico dos sistemas de controle 13
2.2 Controle em malha fechada 14
2.3- Controlador PID 16
2.3.1- Ao Proporcional 17
2.3.2- Ao Integral 18
2.3.3- Ao Derivativa 19
2.4- Controlador FUZZY PI 19
2.5- Controle de sistemas de climatizao 21
3- MICROCONTROLADORES 24
3.1- Arquiteturas dos microcontroladores 25
3.1.1- Arquitetura CISC 25
3.1.2- Arquitetura RISC 26
3.2- Principais Componentes de um microcontrolador 26
3.2.1- Memria 26
3.2.2- Arithmetic Logic Unit (ALU) 27
3.2.3 Temporizadores e contadores 27
3.2.4 Interfaces de entrada e sada 27
3.2.5 Interrupes 27
3.3- Microcontroladores PIC 28
3.3.1- Microcontrolador PIC18F4550 29
3.3.1.1- Diagrama de pinos PIC18F4550 30
3.3.1.2- Diagrama de blocos PIC18F4550 30
3.3.1.3- Organizao da Memria de Programa 32
3.3.1.4- Memria de Dados 32
3.3.2- Comunicao USB/CDC em microcontroladores PIC 34
4- ESTUDO DE CASO 35
4.1- O objeto de estudo 35
4.2- Proposta do sistema de controle 37
4.2.1- Microcontrolador 37
4.2.2- Sensor LM35 37
4.2.3- Ventoinha 38
4.3- Montagem do sistema de controle 39
4.4- Desenvolvimento do software de controle 41
4.5- Aplicao Web 43
4.6- Resultados obtidos 44
5- CONCLUSES 47
REFERNCIAS BIBLIOGRFICAS 48

ANEXO I (Cdigo)




LISTA DE FIGURAS
Figura 2.1 Diagrama de blocos de um sistema de controle em malha fechada 14
Figura 2.2 Regies das combinaes possveis entre as entradas 21
Figura 3.1 Desenho esquemtico de um microcontrolador. 25
Figura 3.2 Microcontrolador PIC18F4550 29
Figura 3.3 Diagrama de pinos DIP do microcontrolador PIC18F4550. 30
Figura 3.4 Diagrama em Blocos do PIC18F4550. 31
Figura 3.5 Organizao da Memria do PIC18F4550. 32
Figura 3.6 Memria de Dados do PIC18F4550. 33
Figura 4.1 Viso frontal e lateral da maquete. 33
Figura 4.2 Viso traseira e lateral da maquete 36
Figura 4.3 Viso superior do telhado da maquete 36
Figura 4.4 Sensor LM35 38
Figura 4.5 Ventoinha 39
Figura 4.6 Kit Picminas e Protoboard 40
Figura 4.7 Sistema de controle montado 40
Figura 4.8 Diagrama eltrico. 41
Figura 4.9Diagrama USB/CDC 42
Figura 4.10 Tomcat Servidor 43
Figura 4.11 Tela principal. 44
Figura 4.12 Mdulo NI USB-6009 45
Figura 4.13 Evoluo temporal da temperatura interna do ambiente. 46

LISTA DE TABELAS
Tabela 2.1 Efeitos no sistema das aes proporcional, integral e derivativa. 17










LISTA DE ABREVIATURAS

USB - Universal Serial Bus Barramento universal serial
CDC - Communications device class - Comunicaes classe de dispositivo.
HTML - HyperText Markup Language - Linguagem de marcao de Hipertexto.
HVAC - Heating, Ventilation and Air Conditioning Aquecimento, Ventilao e
condicionamento de Ar.
CISC- Complex Instruction Set Computer. Conjunto de instrues complexas.
RISC Reduced instruction Set Computer - Conjunto reduzido de instrues de
computador.
RAM Random Access Memory - Memria de Acesso Aleatrio.
EEPROM Electrically Erasable Programmable Read-Only Memory - Memria
eletricamente apagvel somente leitura programvel.
ALU - Arithmetic Logic Unit - Unidade lgica e aritmtica.
HID - Human interface device class - Classe de dispositivos de interface humana
P Proportional Proporcional
D Derivative Derivativo
I Integral Integral























LISTA DE SMBOLOS

) (t e o sinal de erro do processo;
p
k o ganho proporcional do controlador PID.
i
T denominado tempo integral do controlador PID (s)
d
T o Tempo derivativo do controlador PID (s)
( ) nT u
PI
a ao de controle no instante atual do controlador fuzzy PI.
( ) T nT u
PI

a ao de controle no instante passado do controlador fuzzy PI.
( ) nT u A
incremento da ao de controle do controlador fuzzy PI.
u
K o ganho de sada do controlador fuzzy PI.
i
K
uma constante de sintonia do controlador fuzzy PI.
K
uma constante de sintonia do controlador fuzzy PI.
( ) T nT r
a variao do erro do controlador fuzzy PI.
( ) T nT e
o erro anterior do controlador fuzzy PI.
L a faixa das variveis de entrada do controlador fuzzy PI






















RESUMO

O aumento da preocupao do homem com relao a seu bem estar e conforto uma coisa
inerente evoluo da humanidade. Quanto mais evoludas se tornam as pessoas mais
exigentes ficam com relao a seu conforto e bem estar. O uso de aparelhos que permitem o
condicionamento do ambiente uma tcnica comumente usada e difundida no cenrio atual.
No entanto, o uso de aquecimento e/ou resfriamento artificiais de ar em edificaes causam
um grande impacto do ponto de vista energtico e ambiental. Tais aparelhos consomem
grande quantidade de energia e so responsveis por 1/3 da energia consumida. No cenrio
brasileiro, o uso do ar condicionado e a iluminao so responsveis por 48 % do consumo
de energia eltrica no setor de edifcios comerciais e pblicos. Diante disso, a busca por
sistemas de climatizao que garantem um menor consumo de energia uma rea
tecnolgica bastante promissora nos prximos anos. Nesse contexto a escolha das tcnicas
de controle, utilizadas em ambientes, como o controle da temperatura e umidade do ar,
podem ter um impacto significativo no consumo de um sistema de climatizao de
ambientes. O controle on-off comumente utilizado nesse tipo de sistema, porm, tal
controle possui uma baixa robustez e um baixo rendimento energtico. Neste trabalho
apresenta-se o controle fuzzy PI como uma tcnica alternativa para o controle da
temperatura interna do ambiente construdo e realiza-se um estudo sobre como implementar
os controladores nebulosos num sistema de climatizao, visando obter as condies de
conforto dos usurios. O sistema de controle proposto tem como base um microcontrolador
PIC18F4550 e aplicado em um modelo de edificao em escala reduzida. O
microcontrolador capaz de comunicar-se via USB/CDC com um computador, o que
possibilita a visualizao da dinmica do sistema de controle em tempo real. O software de
aquisio e visualizao de dados desenvolvidos uma aplicao web e foi desenvolvido na
plataforma HTML/JavaScript. Por ser uma aplicao web, possvel a visualizao do
sistema de controle de qualquer ponto na rede, visto que a maquina servidor opera como um
servidor local. Alm de uma interface IHM muito amigvel, o sistema de controle
desenvolvido neste trabalho apresentou desempenho adequado, mostrando-se robusto com
relao s perturbaes impostas intencionalmente no ambiente.

Palavras-chave: controle fuzzy, controle inteligente, conforto trmico, comunicao
CDC




ABSTRACT

The increase of man's concern with respect to your well being and comfort is something
inherent in the evolution of humanity. The more advanced people become, the more
demanding are in relation to their comfort and welfare. The use of devices that enable
the environmental conditioning is a technique commonly used and widespread in the
current scenario. However, the use of heating and/or artificial cooling of air in buildings
cause a great impact in terms of energy and environmental. Such devices consume large
amounts of energy and are responsible for 1/3 of the energy consumed. In the Brazilian
context, the use of air conditioning and lighting account for 48% of electricity
consumption in the sector of commercial and public buildings. Therefore, the search for
HVAC systems that ensure a lower consumption of energy is a promising area of
technology in the coming years. In this context the choice of control techniques, used in
environments such as control of temperature and humidity, can have a significant
impact on the consumption of an HVAC system environments. The on-off control is
commonly used in this type of system, however, such control has a low strength and
low energy efficiency. This paper presents the fuzzy PI control as an alternative
technique to control the internal temperature of the built environment and carried out a
study on how to implement the fuzzy controllers in HVAC system, to obtain conditions
for the comfort of users. The proposed control system is based on a PIC18F4550
microcontroller and is applied in a model of building small-scale. The microcontroller is
able to communicate via USB/CDC with a computer, which enables the visualization of
the dynamics of the control system in real time. The acquisition software and data
visualization developed is a web application platform and was developed in
HTML/JavaScript. Being a web application, it is possible to visualize the control system
anywhere on the network, since the server machine operates as a local host. In addition
to a very friendly HMI interface, the control system developed in this study presented
adequate performance, proving to be robust with respect to perturbations in the
environment intentionally inflicted.

Keywords: fuzzy control, intelligent control, thermal comfort, USB/CDC Communication



1- INTRODUO

O organismo humano se relaciona com o meio ao seu redor respondendo a estmulos
como luz, som, calor, ventos, entre outros, e busca se adaptar utilizando o mnimo de
energia possvel, por meio de um conjunto de reaes de ordem fisiolgica e
psicolgica. Estas reaes so, em geral, respostas s condies ambientais que um
determinado espao arquitetnico, em torno do individuo, pode propiciar.

No entanto, a sensao de conforto no depende apenas dos estmulos que o ambiente
construdo, no qual o homem esta inserido, pode propiciar. Essa sensao de conforto
influenciada tambm por fatores ligados a experincias pessoais anteriores de cada
individuo, onde este fator, por sua vez, garante que nem todas as pessoas em um mesmo
ambiente possuem mesmo de satisfao do conforto trmico (ASHRAE 55: 2004).

De modo geral, os estmulos do meio podem ser medidos com mais facilidade que as
sensaes, pois estas correspondem ao sentimento e avaliao subjetiva sobre o
ambiente. As condies de conforto e, conseqentemente, a sensao de conforto,
envolvem um conjunto significativo de fenmenos inter-relacionados, que podem ser
agrupados em um conjunto representativo de exigncias mnimas. Em linhas gerais,
estas exigncias correspondem s caractersticas que um ambiente deve apresentar para
o desempenho adequado e confortvel de diversas atividades humanas. Tais exigncias
podem ser sintetizadas como a faixa de temperatura e umidade do ar relativas ao
conforto trmico; o conforto visual, que se relaciona com a iluminao do ambiente; o
conforto acstico, que esta relacionada com os nveis de rudos e ao isolamento
acsticos; o conforto tctil, relativo s condies de eletricidade esttica, rugosidade,
umidade e temperatura das superfcies; e tambm a qualidade do ar e a presena de
odores.

Embora sejam diversos os elementos que contribuem para a sensao de conforto,
caracterizada pela intensidade das respostas fisiolgicas e psicolgicas do individuo ao
meio que o cerca, a satisfao do ambiente trmico representa o fator predominante e
que modifica, alm das reaes de carter subjetivo aos estmulos do meio ambiente
9

fsico, outros fatores que contribuem para sensao de conforto, tais como idade, raa,
sexo, adaptabilidade ao meio, atividade fsica realizada (XAVIER, 1999, 2005).

O conforto trmico tem sido durante as ltimas dcadas objeto de muitas pesquisas, que
se tem por base a compreenso de como essa situao pode ser atingida, de que maneira
ela se processa, quais variveis que a envolvem, quais so os ndices mais relevantes,
quais seus efeitos sobre a sade e produtividade humana e tambm quais fatores que a
ela podem ser relacionados (FANGER, 1972; SZOKOLAY, 1987, GIVONI, 1976, 1992).

A pesquisa em conforto ambiental nas edificaes tem procurado tomar novas atitudes
frente arquitetura e a automao predial. Em fase do pr-projeto da edificao feita
uma anlise sobre o material a ser utilizado, o clima do local e as variveis construtivas
da planta da edificao. Quando se pretende alcanar as condies de conforto num
ambiente j construdo, usam-se artifcios da automao predial acopladas s tcnicas de
controle para condicionamento do ambiente. No entanto, apesar dos vrios fatores que
influenciam o conforto dos usurios de uma edificao, as condies internas de
conforto de um ambiente so ditadas basicamente pelo valor da temperatura e umidade
relativa do ar.

As tcnicas de controle aplicadas visam atender os pr-requisitos de projeto. Estes pr-
requisitos podem estar relacionados, por exemplo, manuteno da temperatura e/ou
umidade do ambiente em torno de uma referncia estabelecida pelo projetista, em
funo das exigncias dos usurios.

Ao se projetar um sistema de controle, imprescindvel em algumas ocasies o
conhecimento do modelo matemtico do processo. Porm, quando o sistema possui um
modelo bastante complexo ou de natureza no linear, em alguns casos, essa
modelagem pode ser complicada. No entanto, possvel que um operador humano seja
capaz de controlar diversos sistemas sem compreender a matemtica, ou todos os
detalhes fsicos envolvidos.

Se opondo aos controladores convencionais, em que se descreve analiticamente o
algoritmo por equaes diferenciais ou algbricas, no controle fuzzy utiliza-se regras
10

lgicas no algoritmo de controle, visando assim a incorporao da experincia humana
nas rotinas de controle. Os controladores fuzzy so bastante robustos e com grande
capacidade de incorporar conhecimentos de outros sitemas (ZADEH
1
, 1965, apud
SANDRI; CORREA, 1999). Estes controladores so considerados modelos versteis
quanto se tem um modelo fsico de alto grau de complexibilidade e difcil representao
matemtica (SANDRI; CORREA, 1999).

1.1. Descrio do problema

Com o intuito de avaliar as interaes trmicas do ambiente externo com o ambiente
interno de uma edificao, desenvolveu-se um prottipo de um modelo de edificao
em escala reduzida.

Propem-se o controle fuzzy de temperatura capaz de manter a temperatura interna do
ambiente em escala reduzida em um valor constante, visto que os controles
convencionais no apresentam um desempenho robusto devido a complexidade do
sistema. O controlador fuzzy desenvolvido ser baseado em um controlador PI,
resultando em um controlador fuzzy PI.

Realiza-se o controle fuzzy em um dispositivo microcontrolador PIC184550, que por
sua vez se comunica com o computador via comunicao USB/CDC, garantindo a
visualizao das variveis do sistema em tempo real. As variveis so apresentadas em
uma aplicao web desenvolvida em JavaScrip.

A atuao no sistema feita com o objetivo de manter a temperatura do sistema no
valor de referncia. Se a temperatura maior que a de referncia do sistema, o atuador
tem a capacidade de insuflar uma massa de ar frio no ambiente interno, fazendo com
que o ambiente se resfrie at a temperatura de referncia.




1
ZADEH, L. A. Fuzzy Sets, Information and Control. 1965, v. 8, p. 338-353.

11

1.2. Objetivo

Estudar, implementar e analisar um sistema de controle fuzzy PI de temperatura num
modelo de edificao em escala reduzida utilizando um microcontrolador PIC18F4550
interfaceado com um microcomputador via USB/CDC.

1.3. Metodologia

O desenvolvimento do trabalho engloba: (a) reviso sobre conforto trmico, lgica
Fuzzy, controle fuzzy PI, microcontroladores, desenvolvimento de softwares; (b)
montagem do modelo do ambiente em escala reduzida; e (c) proposio e
implementao do sistema de controle no ambiente.

A execuo do trabalho foi baseada no seguinte roteiro de atividades:

- Estudo de como desenvolver, na prtica, um sistema de controle nebuloso
(fuzzy) que seja baseado em um controlador PI;
- Estudos sobre o microcontrolador PIC18F4550.
- O desenvolvimento e montagem do sistema de controle no microcontrolador
PIC18F4550.
- Sintonia do controlador;
- Desenvolvimento da comunicao do microcontrolador com um
microcomputador.
- Desenvolvimento de um Software para a aquisio de dados e monitoramento do
controle proposto;

1.4. Estrutura do trabalho

O presente trabalho encontra-se estruturado em cinco captulos mais a lista de
referncias bibliogrficas e um anexo.

12

No captulo 1 apresenta-se uma introduo, uma descrio do problema proposto e uma
apresentao dos objetivos e da metodologia adotada para o desenvolvimento do
trabalho.

No Captulo 2 aborda-se uma discusso sobre sistemas de controle e so apresentados
fundamentos de diversas tcnicas de sistemas de controle. Aborda-se o problema de se
modelar matematicamente sistemas reais e quando se utilizar controle nebuloso. Ao fim
apresenta-se as equaes do controlador fuzzy PI utilizado no presente trabalho.

No Captulo 3 so abordados os fundamentos dos microcontroladores. feita uma
descrio detalhada do microcontrolador PIC18F4550 pertencente famlia PIC18
da MICROCHIP.

No Captulo 4 apresenta-se o desenvolvimento prtico do trabalho desenvolvido.
apresentado os componentes eletrnicos utilizados na montagem bem como os
diagramas de ligao e resultados obtidos. Alm disso, realiza-se uma abordagem
acerca da aplicao web desenvolvida em HTML/JavaScript.

No Captulo 5 feita uma abordagem conclusiva sobre o trabalho.

Finalmente so apresentadas as referncias bibliogrficas utilizadas, e um anexo
apresentando o cdigo fonte do software desenvolvido para o microcontrolador no
software MPLAB IDE V8.60.


2- SISTEMAS DE CONTROLE


Embora muitas vezes no se perceba todos os dias participa-se ativamente ou
passivamente de diversos sistemas de controle. Sempre que o ser humano participa de
um determinado processo com a funo de monitor-lo, est participando do
fechamento de uma malha. O primeiro dispositivo que utilizava controle em malha
fechada que se tem conhecimento o relgio de gua inventado por volta de 300 a.C.
Este relgio operava por meio do gotejamento de gua, a uma taxa constante, dentro de
um reservatrio medidor. O nvel do reservatrio medidor podia ser usado para informar
o tempo decorrido (HEY, 1997).

2.1- Histrico dos sistemas de controle

No decorrer dos anos vrios trabalhos contriburam para consolidao da teoria de
controle na atualidade. Segundo Ogata (2003) o primeiro trabalho significativo de
controle automtico foi o regulador centrfugo construdo por James Watt para o
controle de velocidade de uma mquina a vapor, no sculo XVIII.

Alguns termos importantes surgiram no decorrer do desenvolvimento do controle
automtico, como, por exemplo, o prprio termo automtico que implica no controle
efetuado sem a interveno humana e o termo realimentado que foi utilizado pela
primeira vez nos Estados Unidos em 1920 quando do desenvolvimento de sistemas
telefnicos e amplificadores eletrnicos de realimentao por Bode, Nyquist e Black na
Bell Telephone Laboratories (DORF; BISHOP, 2005).

Durante a dcada de 1940, por exemplo, os mtodos de resposta de freqncia tornaram
possvel aos engenheiros projetar sistemas de controle em malha fechada satisfazendo
os requisitos de desempenho. Nesta mesma dcada, Walter R. Evans trabalhando na
indstria aeronutica desenvolveu uma tcnica grfica para traar as razes de uma
equao caracterstica de um sistema com retroao cujos parmetros mudam de valor
sobre uma faixa particular de valores, tal mtodo denominado lugar das razes foi o
principal mtodo para projetos de sistemas de controle neste perodo (OGATA, 2003).

14

Tendo em vista que os sistemas modernos, dotados de muitas entradas e muitas sadas,
se tornam cada vez mais complexos, a descrio de um sistema de controle envolve um
grande nmero de equaes. A teoria de controle clssica, que trata somente de sistemas
com uma nica entrada e uma nica sada, tornou-se insuficiente para lidar com
sistemas de entradas e sadas mltiplas. A partir de 1960, a disponibilidade dos
computadores digitais tornou possvel a anlise, no domnio do tempo, de sistemas
complexos, ensejando o desenvolvimento da moderna teoria de controle baseada nas
tcnicas de anlise e sntese por meio de variveis de estado. Esta teoria foi
desenvolvida com o objetivo de tratar a complexidade crescente dos sistemas modernos
e atender s rigorosas exigncias quanto ao peso, exatido e custos de projetos relativos
s aplicaes militares, espaciais e industriais.

Durante o perodo de 1960 a 1980, foram investigados os controles timos de sistemas
determinsticos e estocsticos bem como o controle adaptativo e o controle com
aprendizado. De 1980 aos dias de hoje, os desenvolvimentos na moderna teoria de
controle tm se concentrado no controle robusto.

2.2- Controle em malha fechada

O controle de sistemas em malha fechada utiliza um sinal de medio atual da sada do
sistema para comparar com um sinal de referncia previamente estabelecido. O sinal de
sada medido chamado de sinal de realimentao ou feedback. Na figura 2.1 mostra-se
o diagrama de blocos e o fluxo de informaes de um sistema de controle em malha
fechada SISO (Single Input Single Output).


Figura 2.1 Diagrama de blocos de um sistema de controle em malha fechada

15

onde R(S) o sinal de entrada; Y(S) o sinal de sada da planta e E(S ) o sinal de erro
atuante (diferena entre R(S) e Y(S)). Em geral, indica-se a funo de transferncia
(modelo matemtico) de malha fechada por T(S ), a funo de transferncia no caminho
da alimentao direta e representada por G(S ) e a funo de transferncia no caminho
da realimentao por H(S ). Tem-se, portanto, que a funo de transferncia em malha
fechada para o diagrama apresentado

) ( ) ( ) ( 1
) ( ) (
) (
) (
) (
s H s G s Gc
s Gp s Gc
s R
s Y
s T
+
= =
(2.1)

O elemento de medio (sensor) a parte do sistema responsvel por realizar a medio
de alguma propriedade do sistema, bem como a sua converso em alguma varivel
fsica que possa ser interpretada pelo sistema de controle. Em alguns casos, isto no
ocorre e torna-se necessrio a utilizao de elementos transdutores e transmissores para
converter e adequar o sinal ao sistema de controle. Ocorre em muitos casos tambm de
o prprio elemento sensor ser o elemento transdutor do sinal. O sinal obtido pelo
elemento de medio , ento, enviado ao controlador, que a parte mais importante do
sistema de controle. O controlador funciona como o crebro do sistema, tomando
decises baseadas em informaes disponveis e repassando-as ao elemento final de
ao (atuador). O atuador o elemento do sistema de controle responsvel por exercer a
ao sobre o processo de modo a coloc-lo dentro dos padres desejados.

Um sistema de controle em malha fechada utiliza-se de uma funo que relaciona o
sinal de sada com o sinal de entrada. Geralmente a diferena entre o sinal de sada e o
sinal de entrada (sinal de erro do sistema) de um processo sob controle amplificada e
utilizada no controle do processo, fazendo com que a diferena entre estes sinais seja
reduzida. O controle de um sistema por meio de uma malha fechada oferece inmeras
vantagens. O uso da realimentao faz com que a resposta do sistema seja relativamente
insensvel a distrbios e variaes internas dos parmetros do sistema (OGATA, 2003).
Dessa maneira, pode-se utilizar componentes relativamente imprecisos e baratos para
obter o controle preciso de determinado sistema. Por outro lado, um sistema de controle
em malha fechada faz com que o nmero de componentes e a complexidade no sistema
16

de controle aumentem, dentre eles o sensor que, geralmente, o elemento de maior
custo do sistema de controle. Alm disso, os sensores podem introduzir rudos e
imprecises no sistema.

O controle em malha fechada utilizado para fornecer o mximo de desempenho e
robustez ao sistema. Qualitativamente, o desempenho de um sistema de controle pode
ser avaliado pela sua capacidade em manter a varivel controlada prximo a um valor
desejado, mesmo em presena de perturbaes externas. A robustez deve proporcionar
ao sistema de controle um bom desempenho tanto para pequenas quanto para grandes
perturbaes.

2.3- Controlador PID

O controlador PID (proporcional, integral e derivativo) de longe o algoritmo de
controle mais utilizado. A maior parte dos sistemas em malha fechada so controlados
pelo PID ou por esse algoritmo com pequenas variaes. Esse tipo de controlador tem
sua sada da seguinte forma

|
|
.
|

\
|
+ + =
}
1
0
) (
) (
1
) ( ) (
dt
t de
T d e
T
t e k t u
d
i
p
t t
(2.2)

onde ) (t u o sinal de controle;
p
k o ganho proporcional do controlador; ) (t e o sinal
de erro do processo;
i
T denominado tempo integral do controlador e
d
T o Tempo
derivativo do controlador.

O ajuste de um controlador PID, que denominado sintonia do controlador, feito
variando os valores de
p
k ,
i
T e
d
T . Na tabela 3.1 apresenta-se um resumo da influncia
das aes proporcional, integral e derivativa no controlador PID.




17


Tabela 2.1 Efeitos no sistema das aes proporcional, integral e derivativa.
Ao Tempo de
Subida
Sobreelevao Tempo de
Estabelecimento
Erro Estacionrio
Proporcional Diminuio Aumento Sem Alterao Diminuio
Integral Diminuio Aumento Aumento Elimina
Derivativo Sem alterao Diminuio Diminuio Sem Alterao
Fonte: LOURENO, 1997.

O processo de selecionar parmetros do controlador que garantam uma dada
especificao de desempenho foi bastante estudado por Ziegler-Nichols (1942, apud
OGATA, 2003). Eles sugeriram regras para a sintonia de controladores PID baseadas na
resposta experimental ao degrau ou no valor de Kp que resulta em uma estabilidade
marginal, quando somente uma ao proporcional utilizada. As regras sugerem um
conjunto de valores
p
k ,
i
T ,
d
T . que vo proporcionar uma operao estvel ao sistema.
Contudo, o sistema resultante pode exibir um mximo sobre-sinal grande devido
resposta ao degrau, o que e inaceitvel. Nesse caso, e necessrio fazer uma srie de
sintonias finas at que um resultado aceitvel seja obtido. De fato, as regras de Ziegler-
Nichols
2
(1942, apud OGATA, 2003) fornecem estimativas dos valores dos parmetros
e proporcionam um ponto de partida na sintonia fina, e no os valores definitivos de
p
k ,
i
T ,
d
T logo na primeira tentativa (OGATA, 2003).

Ziegler e Nichols
2
(1942, apud OGATA, 2003) propuseram dois mtodos para a
sintonia de controladores PID. O primeiro mtodo baseado em um processo de malha
aberta, ao passo que o segundo mtodo baseado no ganho crtico da malha fechada.

2.3.1- Ao Proporcional

No controle puramente proporcional a ao de controle proporcional ao sinal de erro
atuante e sua equao descrita da seguinte forma:

2
Ziegler, J. G. And N. B. Nichols (1942). Optimum Settings for Automatic Controllers,
Trans. ASME, 64, 759-768.

18


) ( ) ( t E K t g
p C
= (2.3)

onde ) (t g
C
a sada do controlador;
p
K o ganho proporcional e E(t) o erro atuante
no processo.

Para que o sinal de erro atuante seja nulo, necessrio que o valor da varivel
manipulada seja igual ao valor de referncia (setpoint). Quando a condio desejada, ou
seja, valor da varivel manipulada igual ao setpoint, nenhuma energia entregue ao
processo, o que faz com que volte a surgir um sinal de erro. Por causa disto, um
controle puramente proporcional nunca consegue atingir a condio desejada. Muitos
controladores que operam apenas no modo proporcional adicionam um valor constante
varivel manipulada para garantir que na condio desejada alguma energia seja
entregue ao sistema. Este valor denominado bias (polarizao) e quando ajustvel
permite que se obtenha uma estabilizao prxima da condio desejada. Este tipo de
controle uma forma simples de controle realimentado (ASTROM; HAGGLUND,
1988).

2.3.2- Ao Integral

A ao integral atua de sistema gerando uma resposta na sada do controlador que
proporcional a amplitude e durao do sinal de erro atuante. A ao integral tem o efeito
de eliminar o erro caracterstico de um controle puramente proporcional. A ao integral
funciona da seguinte maneira: em intervalos regulares, a ao integral corrige o valor da
varivel manipulada, somando a esta o valor do erro atuante. Este intervalo de tempo
o tempo integral (Ti). Na equao (2.4) descreve-se matematicamente uma ao de
controle integral.

| |
}
+ = dt t E k t E K t g
i p c
) ( ) ( ) (
(2.4)

A ao integral adiciona um plo na origem da funo de transferncia do controlador,
eliminando assim o erro estacionrio de posio, independentemente do sistema que se
19

pretende controlar. Se, por um lado, como j referimos anteriormente, a ao integral
elimina o erro estacionrio, por outro, ela aumenta o tempo de estabelecimento e piora a
estabilidade relativa, o que usualmente indesejvel (LOURENO, 1997).

2.3.3- Ao derivativa

A funo da ao derivativa melhorar a estabilidade em malha fechada do sistema.
Assim como o controle integral, o controle derivativo no , isoladamente, uma tcnica
de controle, pois no empregado sem o acompanhamento de uma ao de controle
proporcional. A ao de controle derivativa consiste em uma resposta na sada do
controlador que proporcional a velocidade de variao do erro atuante, conforme se
descreve na equao (2.5).

(

+ =
dt
t dE
K t E k t g
d p C
) (
) ( ) (
(2.5)

A ao derivativa tem o efeito de reduzir a velocidade das variaes do valor da
varivel controlada, evitando que ela se eleve ou reduza muito rapidamente.

O termo derivativo s atua quando h variao no erro. Se o processo esta estvel, seu
efeito nulo. Durante perturbaes ou na partida do processo, quando o erro est
variando, o derivativo sempre atua no sentido de atenuar as variaes, sendo, portanto, a
sua principal funo melhorar o desempenho do processo em regime transitrio.

Embora o controle derivativo no afete diretamente o erro estacionrio, ele aumenta o
amortecimento do sistema, permitindo, assim, a utilizao de um valor mais levado do
ganho K , o que vai resultar em maior preciso de regime permanente (OGATA, 2003).

2.4- Controlador fuzzy PI

Quando se pretende aplicar os conceitos fuzzy em sistemas tem-se a necessidade de se
determinar a lei de controle. Esta lei relaciona as entradas do sistema com a sada do
controlador. A relao entre entradas e sadas no controlador fuzzy obtida por meio de
20

conhecimentos especialistas do sistema, ou seja, tcnicas de inteligncia artificial.
Geralmente a lei de controle apresentada como uma frmula matemtica discreta,
possibilitando assim o uso do controle em qualquer dispositivo digital que tenha
capacidade de realizar clculos (Controladores lgicos programveis, DSP,
microcontroladores).

Existem varias etapas para se obter as equaes de um controlador fuzzy PI. Dentre
essas etapas esto a fuzzificao das entradas, a base de regras do controlador e a
defuzzificao. A deduo da lei de controle do controlador fuzzy PI apresentada em
Oliveira (2008) e tem como base as seguintes equaes.

( ) ( ) ( ) nT u K T nT u nT u
PI u PI PI
A + =
(2.6)

( )
( ) ( ) | |
( ) ( ) T nT e K L
nT r K T nT e K L
nT u
i
i

+
= A
2 2

Nas regies IC1, IC2, IC5 e IC6 (2.7)
( )
( ) ( ) | |
( ) ( ) nT r K L
nT r K T nT e K L
nT u
i

+
= A
2 2

Nas regies IC3, IC4, IC7 e IC8 (2.8)
( ) ( ) | | L nT r K nT u + = A
2
1
Nas regies IC9 e IC10 (2.9)
( ) ( ) | | L T nT e K nT u
i
+ = A
2
1
Nas regies IC11 e IC12 (2.10)
( ) ( ) | | L nT r K nT u = A
2
1
Nas regies IC13 e IC14 (211)
( ) ( ) | | L T nT e K nT u
i
= A
2
1
Nas regies IC15 e IC16 (2.12)
( ) 0 = A nT u Nas regies IC18 e IC20 (2.13)
( ) L nT u = A Nas regies IC17 (2.14)
( ) L nT u = A Nas regies IC19 (2.15)

onde
( ) nT u
PI
a ao de controle no instante atual;
( ) T nT u
PI

a ao de controle no
instante passado;
u
K ganho de sada do controlador fuzzy;
( ) nT u A
o incremento da
ao de controle;
i
K
e
K
so constantes de sintonia do controlador PI;
( ) T nT e
o
21

erro do controlador(Varivel de entrada);
( ) T nT r
a variao do erro anterior do
controlador (Varivel de entrada); L a faixa das variveis de entrada do controlador.
Os valores de entradas definem as regies do controlador que esta trabalhando. Na
figura 2.2 exemplifica-se a definio das regies citadas nas equaes (2.7) a (2.15).


Figura 2.2 Regies das combinaes possveis entre as entradas
Fonte: Adaptada de TANG; CHEN; LU, 2001

2.5- Controle de Sistemas de Climatizao

Existem vrios tipos de abordagens para tratar o problema de conforto trmico em
edificaes climatizadas artificialmente. Tais solues visam promover melhores
condies de conforto trmico no interior de ambiente.

Em controle de ambientes, a abordagem mais difundida a que faz o tratamento das
condies climticas no interior do ambiente tomando-se como parmetros de controle a
otimizao tanto da temperatura como da umidade relativa do ar. O controle em malha
22

fechada tpico nesse tipo de abordagem abordagem realizado com a realimentao do
sinal de temperatura e umidade relativa, que mensurado atravs de sensores no
ambiente no qual se efetua a climatizao artificial. Nas ultimas dcadas vrios
trabalhos foram desenvolvidos nessa perspectiva. Na seqncia apresenta-se alguns
trabalhos relacionados com essa abordagem onde procura-se compreender os pontos
positivos e negativos em variar as duas principais variveis que afetam as condies
higrotrmicas no interior de uma edificao.

Astrom,; Hagglund e Wallenborg (1993) apresentam uma tentativa de otimizao
melhorando o desempenho de controladores digitais em sistemas HVAC(heating,
ventilation, and air conditioning) por meio de um mecanismo de auto-ajuste. Utilizando-
se de estruturas de controle digitais, evitando-se assim problemas de discretizao de
estruturas contnuas para tratamento das variveis consideradas no sistema, apresenta-se
uma melhora no desempenho para sistemas de baixa ordem, atuando-se na temperatura
interna do ambiente e na presso dos dutos de ventilao do sistema.

J Dumur; Boucher e Murphy (1997) propem uma estratgia que antecipa futuras
mudanas no set-point de temperatura para manter o sinal o mais prximo possvel do
valor ideal. Tal estratgia, primeiramente testada em controladores do tipo proporcional,
integral e derivativo (PID), proposta para um controlador preditivo generalizado
(GPC).

Oliveira et al. (2003) verificam que no contexto de conforto, para se obter a sensao
de conforto trmico, pode ser suficiente ajustar uma faixa de temperatura em virtude de
se obter um controle regularizado em um valor pr-estipulado. Tal caracterstica ento
explorada por uma lei de controle baseada em sistemas fuzzy.

Pode-se citar ainda, como estratgia de controle para temperatura e umidade relativa, o
trabalho proposto por Rentel-Gomez e Velez-Reyes (2001) onde, desprezando-se a
hiptese de alto consumo de energia, utiliza-se de uma tcnica de controle multivarivel
de temperatura e umidade relativa em cascata para manter seus respectivos valores o
mais prximos possvel dos set-points pr-determinados. A estratgia de controle
proposta possui dois laos na malha de controle, o lao interno utiliza-se de uma lei de
23

controle no-iterativa para desacoplar as duas variveis de sada (temperatura e umidade
relativa internas do ambiente) em relao as entradas (variveis do sistema de
climatizao e perturbaes), j o lao externo, voltado a estabilizao e controle
propriamente dito, utiliza-se de um controlador do tipo proporcional e derivativo (PD).
Apresentam-se ainda resultados onde atuam-se em cada varivel separadamente,
considerando-se nulas as infiltraes entre o ambiente e o clima externo.

No trabalho em questo, utiliza-se uma malha de controle baseado no controle
regulatrio da temperatura interna do modelo de edificao em escala reduzida. Esse
controle tem por objetivo manter a varivel de processo (temperatura) em valores
desejados (setpoints), ou oscilando em faixas pr-definidas. A atuao do controlador
feita com a insuflao de ar frio na instalao a partir de uma ventoinha.
















3- MICROCONTROLADORES

O microcontrolador pode ser definido como um circuito integrado composto por um
microprocessador e dispositivos perifricos. Pode-se dizer que existe dispositivos
perifricos essenciais, tais como: memria de programa e de dados; e tambm
perifricos de acessrios como: interfaces de entrada e sada de dados. Encontra-se em
um microcontrolador vrios dispositivos eletrnicos como conversor analgico digital
(AD), comparadores, interfaces de comunicao como USB/SERIAL, geradores de
pulsos, temporizadores, entre outros. So muito populares devido ao seu baixo custo.
Isso possibilita a utilizao de microcontroladores como solues de vrios projetos que
tem como prioridade o baixo consumo de energia e baixo custo.

Os microcontroladores possuem freqncia de clock de poucos MHz e so considerados
lentos comparados aos microprocessadores utilizados em computadores convencionais,
no entanto ele so bastante adequados para aplicaes tpicas. Alm disso esses
dispositivos consomem pouca energia, variando na faixa de miliwatts de potencia
consumida (HORENSTEIN, 2006).

Outra grande vantagem dos microcontroladores a fcil programao e reprogramao,
o que o torna uma ferramenta importante em vrios sistemas embarcados como
celulares, eletrodomsticos, equipamentos de automao industrial, relgios, alarmes,
brinquedos e outros, pois podem ser desenvolvidos para aplicaes especificas.

Atualmente, grande parte dos componentes eletrnicos utilizados possuem
microcontroladores em sua arquitetura. Os microcontroladores possuem uma
capacidade de processamento que depende da famlia de processadores que os mesmos
utilizam. Apresenta-se a organizao de um microcontrolador padro na figura 3.1.

25


Figura 3.1- Desenho esquemtico de um microcontrolador.
Fonte PICMINAS, 2011.

3.1- Arquiteturas dos microcontroladores

A organizao interna dos microcontroladores pode se dar de vrias formas diferentes, e
isso impactar diretamente em sua capacidade de armazenamento, consumo de energia,
programao e desempenho. Os fabricantes de microcontroladores implementam a
arquitetura organizacional dos microcontroladores seguindo paradigmas e conceitos
consolidados pela computao. As arquiteturas mais utilizadas so a arquitetura CISC
(Complex Instruction Set Computer) e a RISC (Reduced instruction Set
Computer).

3.1.1- Arquitetura CISC

A arquitetura CISC tem como base a utilizao de instrues mais complexas,
objetivando assim a diminuio do numero de instrues que o programa necessita para
ser implementado. Nesses dispositivos o numero de ciclos por instrues pode aumentar
26

assim como o prprio tempo de relgio. Pode-se citar como exemplo de utilizao da
arquitetura CISC os processadores da famlia de microcontroladores Intel 8051, que
possuem cerca de 100 instrues.

3.1.2- Arquitetura RISC

A arquitetura RISC tem como base a utilizao de instrues de baixa complexidade, o
que gera um baixo tempo mdio de execuo das instrues de maquina. Essa reduo
de tempo, por sua vez, gera um menor numero de ciclos por instrues, no entanto, o
numero de instrues utilizadas no programa aumenta consideravelmente em relao a
arquitetura CISC. Pode-se citar como exemplo de utilizao da arquitetura RISC os
microcontroladores da famlia PIC. A exemplo disso tem-se o PIC da famlia 16F que
possui um pouco mais de 30 instrues.
Pode-se dizer que os dispositivos que utilizam a arquitetura RISC tem como objetivo a
reduo mxima do tempo de ciclo de via de dados.

3.2- Principais Componentes de um microcontrolador

Um microcontrolador pode ser subdividido em vrios componentes. A seguir descreve-
se as principais partes dos sistemas microcontrolados.

3.2.1 Memria

Um dos componentes principais de um microcontrolador a memria. A memria de
sistemas microprocessados pode ser dividida em dois grupos, sendo eles: memria de
programa (FLASH) e memria de dados (RAM Random Access Memory e
EEPROM - Electrically-Erasable Programmable Read-Only Memory). A utilizao da
memria de programa est relacionada com o armazenamento de tarefas que o
microcontrolador deve executar. J a memria de dados utilizada para armazenar os
resultados e dados utilizados pelo microcontrolador. Apesar das diferenas, ambas
memrias possuem um tamanho limitado quando se compara com outros dispositivos.


27


3.2.2 Arithmetic Logic Unit (ALU)

Em um microcontrolador, o modulo Arithmetic Logic Unit(ALU) responsvel pelas
operaes lgicas realizadas nesse dispositivo. A ALU considerada a central de
processamento do dispositivo e tipicamente realiza operaes lgicas de comparao
como maior, menor, igual; operaes booleanas como and, or, xor; operaes
aritmticas como adio, subtrao, incrementao, multiplicao e diviso.

3.2.3 Temporizadores e contadores

A noo de tempo e execuo de rotinas nos sistemas microcontrolados realizadas
pelos temporizadores e contadores. Podem gerar pulsos, rotinas em perodos
especficos, entre outros. Seus parmetros so alterveis, tornando o seu uso
programvel para uso especifico ou geral.

3.2.4 Interfaces de entrada e sada

Os microcontroladores se interfaceam com outros dispositivos atravs de portas de
entradas e sadas. Essa transmisso de dados com o meio externo pode ser via
comunicao serial, paralela e USB. Uma comunicao bastante utilizada em
microcontroladores a comunicao USB/CDC no qual a comunicao do tipo serial
emulada na porta USB.

3.2.5- Interrupes

O programa principal pode ser interrompido pelas chamadas rotinas de interrupo.
Pode-se dizer que as interrupes so modificaes que ocorrem no fluxo de controle
causada por uma ao externa. A interrupo opera como um sinal de controle enviado
para CPU, quando se detecta um determinado evento. Aps isso, a CPU forada a
tratar o evento externo. possvel dividir o tratamento de interrupes em trs etapas,
que so descritas a seguir:

28

- deteco da fonte da interrupo, ou seja, qual dispositivo que gerou a ao
externa;

- executar as aes relacionadas com o tipo de interrupo gerado;

- retornar ao ponto do programa em que estava quando iniciou atendimento
interrupo;

Quanto um ou mais dispositivos enviam o sinal de interrupo ao mesmo tempo as
interrupes so atendidas de acordo com o grau de prioridade. So prioritrias para
atendimento as interrupes devidas a:

- emergncias de hardware, tais como atendimento a reset(reinicicalizao) e erros
de hardware (erro de paridade de memria,etc.);

- eventos de alta prioridade;

- E/S de dispositivos de alta velocidade.

3.3- Microcontroladores PIC

Os microcontroladores PIC so uma famlia de dispositivos fabricados pela Microchip.
Esses dispositivos utilizam uma arquitetura RISC e possuem freqncias de clock de at
40MHz. Alm disso, eles podem ter at 2048 Kword de memria de programa e at
3968 bytes de memria RAM. Podem ser encontrados com diversos perifricos
internos, tais como: temporizadores/contadores, memria EEPROM interna, gerador,
comparador, amostrador PWM, conversores A/D de at 12 bits, interface de barramento
CAN, I2C,SPI, entre outros.

Existem basicamente trs famlias de PICs sendo elas diferenciadas pelo tamanho da
palavra de memria de programa: 12,14 e 16 Bits. Todos estes dispositivos possuem um
barramento interno de dados de oito bits. Outra caracterstica importante da arquitetura
PIC reside na semelhana e compatibilidade entre os diversos chips. Isto facilita
grandemente a migrao de um MCU para outro, pois os princpios bsicos e grande
parte dos registradores no diferem entre si (HORENSTEIN, 2006).
29

3.3.1 - Microcontrolador PIC18F4550

O microprocessador PIC18f4550 (figura 3.2) rene, em um circuito integrado, todos os
elementos de uma CPU RISC de alto desempenho, sendo fabricados em
encapsulamentos PLCC, TQFP, DIP ou SOIC. Apresenta-se algumas caractersticas
desse dispositivo (DATASHEET, 2006).

- Frequencia de Operao: 48 MHz; - Memria de Programa (instrues): 16384;
- Memria de Dados (bytes): 2048; - Portas de E/S: Portas A, B, C, D, E; - Total de
Pinos de E/S: 20;
- Total de canais de captura de entrada: 1;
- Comunicao Serial Enhanced UART: 2;
- Comunicao Serial SPI (3-wire/4-wire): 3;
- Comunicao Serial I2C: 2;
- Comunicao Paralela (PMP/PSP): No;
- Streaming Parallel Port (SPP) for USB streaming transfers: Sim;
- Packages: PLCC, TQFP, DIP ou SOIC;
- Set (Instrues): 75/ 83 com Set de Instrues Estendida Habilitado;
- Timers: 4.


Figura 3.2- Microcontrolador PIC18F4550








30

3.3.1.1- Diagrama de pinos PIC18F4550

O diagrama de pinos do PIC18F4550 oferece os nomes de todos os pinos contidos neste
componente. Pode-se observar o diagrama na Figura 3.3:

Figura 3.3: Diagrama de pinos DIP do microcontrolador PIC18F4550.
Fonte: DATASHEET..., 2006.

3.3.1.2- Diagrama de blocos PIC18F4550

Neste diagrama pode-se verificar como cada parte deste componente funcionar. Cada
bloco contm uma funo executada pelo microcontrolador PIC18F4550, figura 3.4:
31


Figura 3.4: Diagrama em Blocos do PIC18F4550.
Fonte: DATASHEET..., 2006.







32

3.3.1.3- Organizao da Memria de Programa

A memria de programa deste componente se comporta conforme o esquema
apresentado na figura 3.5.

Figura 3.5: Organizao da Memria do PIC18F4550.
Fonte: DATASHEET..., 2006.

3.3.1.4- Memria de Dados.

A memria de dados onde o microcontrolador l e escreve dados durante a operao
normal. Geralmente do tipo voltil, embora memrias no-volteis possam ser
33

utilizadas (DATASHEET..., 2006). Observe-se no diagrama mostrado na figura 3.6 a
estrutura de memria de dados do PIC18F4550.

Figura 3.6- Memria de Dados do PIC18F4550.
Fonte: DATASHEET...,2006.



34

3.3.2- Comunicao USB/CDC em microcontroladores PIC

A especificao USB (USB-IF) define classes de comunicao para os mais variados
tipos de comunicao (interrupo, transferncia em massa, etc. Dentre essas classes de
comunicao que o padro USB define, duas classes foram consideradas para
desenvolver dois tipos de comunicao USB: CDC e HID.

A classe de comunicao CDC (Connected Device Configuration),desenvolvida nesse
projeto, se enquadra em uma srie de classes que definem transferncias genricas de
dados, como transferncia de sinais de controle e dados em modems, cabos Ethernet e,
para o caso deste trabalho,transferncias que emulam a transmisso de dados atravs da
comunicao serial RS232 (AXELSON, 1996).

A especificao CDC descreve a subclasse Abstract Control Model(IARSYSTEMS)
para a emulao serial atravs do USB. Basicamente, para que a emulao RS232 possa
ser realizada duas interfaces (classes) USB so necessrias: Communication Interface
Classe Data Interface Class. A primeira interface encarrega-se de notificar ao servidor
neste caso uma estao de controle, um computador pessoal do status da conexo
USB-RS232 oriunda do dispositivo.A segunda interface define a forma como os dados
sero enviados j que, no padro RS 232, os dados so mandados em sua forma crua
(raw data), sem qualquer formatao (AXELSON, 1996).








4. ESTUDO DE CASO

4.1. O objeto de estudo

Este trabalho tem como principal objetivo o estudo, implementao, e anlise de um
sistema de controle fuzzy PI de temperatura num modelo de edificao em escala
reduzida (OLIVEIRA,2008). Alm disso, realizada um interfaceamento do
microcontrolador com um computador, possibilitando, por parte do usurio, a
visualizao e o interfaceamento em tempo real com o sistema de controle.

O modelo de edificao em escala reduzida uma casa de madeira em dimenses
reduzidas. Apresenta-se o modelo nas figuras 4.1, 4.2, 4.3. A maquete possui as
dimenses de 62,5 cm de largura, um comprimento de 62 cm e uma altura de 37 cm.


Figura 4.1 Viso frontal e lateral da maquete
36


Figura 4.2 Viso traseira e lateral da maquete


Figura 4.3 Viso superior do telhado da maquete

37

4.2. Proposta do sistema de controle

No presente trabalho, realiza-se um controle realimentado (feedback) no qual a
temperatura interna a varivel controlada no processo. Objetivando o controle da
temperatura interna do modelo em escala reduzida, desenvolve-se um sistema de
controle que tem a capacidade de insuflar uma massa de ar ao ambiente de maneira que
sua temperatura estabilize num valor pr-estabelecido (setpoint).

Para se obter uma malha de controle em malha fechada, utiliza-se o dispositivo LM35
como sensor, uma ventoinha como atuador e um microcontrolador PIC18F4550, que o
principal responsvel pela aplicao do controle. A seguir, descreve-se alguns dos
componentes utilizados neste estudo.

4.2.1- Microcontrolador

Na presente trabalho, o microcontrolador PIC18F4550, tem um papel muito importante
no sistema de controle. Ele responsvel por calcular a tenso mdia a ser entregue ao
atuador a partir do algoritmo de controle fuzzy, ou seja, ele fornece a potncia
necessria a ventoinha, de maneira que este insufle uma quantidade de ar necessria
para a manuteno da temperatura interna do ambiente em um valor de referncia pr-
estabelecido.

4.2.2. Sensor LM35

O LM35 um sensor de temperatura de preciso fabricado pela National
Semiconductor, figura 4.4. Este dispositivo possui uma tenso de sada diretamente
proporcional temperatura na escala Celsius, sendo de 10 mV/C. O LM35 no
nescessita de qualquer calibrao e possui uma boa exatido, valores de temperatura
com variaes de 0,25 C ou at mesmo 0,75 C dentro da faixa de temperatura de -55
C a 150 C. Como ele possui uma sada de tenso direta, muito fcil realizar-se o seu
interfaceamento com dispositivos de leitura analgicos. No presente estudo, o sinal de
tenso do sensor amplificado por um amplificador operacional e posteriormente
enviado para a porta analgica do microcontrolador.
38



Figura 4.4 Sensor LM35

Este sensor permite uma alimentao VS variando na faixa de 4 a 20 V
dc
e drena apenas
60 A de sua fonte de alimentao, o que gera um baixo aquecimento por efeito joule.
O sensor LM35 pode ser encontrado em vrios tipos de encapsulamentos, cujo a escolha
depende do tipo de aplicao em que se utiliza o dispositivo. O encapsulamento mais
comum o TO-92, que se assemelha muito com um transistor.

4.2.3. Ventoinha

A ventoinha o atuador do sistema de controle, figura 4.5. Este dispositivo tem as
caractersticas de um motor de corrente continua e tem a funo de insuflar uma
quantidade de ar frio no ambiente interno, de tal modo que se mantenha a temperatura
constante em um valor de referncia.

39


Figura 4.5 Ventoinha

O controle da quantidade de ar a ser insuflado no ambiente feito por meio de um
controle da potencia da ventoinha. A potncia desenvolvida no dispositivo controlada
pelo microcontrolador por meio de uma modulao por largura de pulsos. Pode-se
variar o ciclo de trabalho de 0% a 100%. A ventoinha operando com um ciclo de
trabalho de 100 % ir girar em sua velocidade mxima, e consequentemente em sua
tenso mxima, 12V, ao passo que com um ciclo de trabalho de 0 % a ventoinha se
desligada, 0V.

4.3. Montagem do sistema de controle

Inicialmente a montagem do sistema realizada em um protoboard e no kit PicMinas
18F4550, figura 4.6 (TORRES; MARTINS,2010). No interior do ambiente encontra-se
somente o sensor de temperatura, que se comunica com o circuito eletrnico de medio
de temperatura, situado no ambiente externo. Este circuito composto por um
amplificador operacional e duas resistncias. A ventoinha se encontra acoplada em uma
das janelas do modelo de edificao em escala reduzida. Apresenta-se na figura 4.7 o
sistema de controle montado.
40



Figura 4.6 Kit Picminas e protoboard.
Fonte: TORRES; MARTINS,2010.




Figura 4.7 Sistema de controle montado.

Na figura. 4.8 apresenta-se o diagrama eltrico do sistema de controle. Observa-se neste
esquema eltrico que a sada do sensor de temperatura amplificada pelo dispositivo
LM741. Essa amplificao ditada pelas resistncias acopladas ao amplificador e no
presente trabalho de 11 vezes. Verifica-se que quanto maior o sinal de voltagem
entregue ao conversor AD do microcontrolador, maior ser a preciso da medio, logo,
41

a utilizao do LM741 para amplificar a temperatura nos fornece um grande aumento da
preciso do sistema.

Figura 4.8 Diagrama eltrico.

Utiliza-se um diodo em paralelo com a ventoinha, denominado diodo de roda livre. Este
dispositivo tem a funo de proteger o circuito eletrnico, o transistor em particular, de
uma descarga reversa da fora contra-eletromotriz gerada na ventoinha. Com o diodo de
roda livre esta descarga eltrica da fora contra eletromotriz circular em torno do diodo
e no mais no transistor.

Utiliza-se os botes RESET e MUDA SETPOINT, que so responsveis por reiniciar o
sistema e alterar o valor de referencia do controle regulatrio, respectivamente.

Os dados do processo podem ser vistos em dois dispositivos. O primeiro deles o leitor
LCD. No display LCD possvel a leitura da temperatura interna do ambiente, do ciclo
de trabalho do cooler e da temperatura de referncia (setpoint). J a segunda forma de
leitura se baseia no interfaceamento do sistema com o microcomputador, que permite a
visualizao na tela de um computador domestico.

4.4. Desenvolvimento do software de controle

O ambiente de desenvolvimento do software o MPLAB IDE V8.60. No anexo I
apresenta-se os passos de desenvolvimento do software. Essa ferramenta oferece uma
srie de funcionalidades, como gerao do cdigo fonte, compilao e teste do chip
42

escolhido pelo projetista, em um ambiente amigvel e de fcil compreenso. Utilizou-se
a linguagem C. Sendo assim, necessita-se de um compilador para converter essa
linguagem de alto nvel para a linguagem de mquina do microcontrolador.

A escrita do cdigo se subdivide em trs partes. A primeira delas o programa
destinado a aquisio de sinais externos, valores de temperatura, por exemplo, e envio
de sinais para dispositivos externos. Nessa etapa, utiliza-se bibliotecas para converso
analgica/digital, acesso as sadas PWM e interface com o display LCD.

Posteriormente, desenvolveu-se uma parte do cdigo dedicado ao sistema de controle.
Nessa parte, possvel calcular o ciclo de trabalho a ser aplicado na ventoinha a partir
de clculos da lei de controle fuzzy PI.

A ltima parte do software destinada a comunicao USB/CDC, figura 4.9.
realizado o empacotamento dos dados e atravs de uma interface com componentes
eletrnicos, possvel enviar esses dados para um computador que tenha porta USB. Os
dados podem ser observados em tempo real, com taxa de amostragem de 1 s. Os dados
recebidos pelo computador fazem parte de uma emulao da porta serial.


Figura 4.9 Diagrama USB/CDC.

Analisando o sistema com uma viso global, este software faz a leitura do sensor de
temperatura em intervalos regulares, de maneira que se possa compar-la com a
temperatura desejada no ambiente. Com essa comparao, gera-se o sinal de erro do
sistema, que representa a diferena do estado atual para o estado de referncia. Em
seguida, a partir da lei de controle do controlador fuzzy PI, calcula o incremento
necessrio na sada do controlador para controlar a temperatura interna do ambiente.
Esse incremento adicionado a sada atual, e a sada do controlador atualizada,
43

fazendo com que a potncia da ventoinha diminua de acordo com o incremento. Aps a
compilao do software de controle, este dever ser gravado no microcontrolador.

4.5. Aplicao Web

Por meio da conexo USB/CDC os dados so enviados para um computador para o
monitoramento. Desenvolveu-se no presente estudo um software para realizar a
interface homem maquina (IHM) do sistema. Este software uma aplicao web
realizada com o Java Script. A aplicao via web foi desenvolvida no software Eclipse e
permite que qualquer computador ligado na rede seja capaz de monitorar o controle de
temperatura do modelo em escala reduzida. Para disponibilizar a aplicao para web,
utiliza-se o servidor Tomcat, figura 4.10 (SIMPSON,2007).


Figura 10 Servidor tomcat.

Apresenta-se na figura 4.11 a tela principal do sistema de monitoramento desenvolvido.

44


Figura 4.11 Tela principal aplicao Java.

4.6. Resultados obtidos

Com o sistema de controle em malha fechado montado, inicia-se o processo de ajuste e
sintonia do controlador fuzzy PI. Diante das equaes discreta do controlador,
possvel concluir que a sintonia deste sistema depende apenas das constantes K ,
i
K e
u
K e dos parmetros T (tempo de amostragem) e | | L L, (faixa das variveis de
entrada do controlador).

A dinmica de sistemas trmicos caracterizada por uma resposta lenta, com isso
utiliza-se o tempo de amostragem de 1 s. J o parmetro L definido com o valor fixo
igual a 1. Com isso tem-se, 1 = = L T .

Aps vrios experimentos realizados no processo, conclui-se que os melhores valores
dos ganhos do controlador so:

10 = K 1 =
i
K 40 =
u
K

45

O sistema desenvolvido permite ao usurio a visualizao em tempo real do sistema de
controle, no entanto, para se gerar o grfico da evoluo temporal da temperatura,
utiliza-se o mdulo NI USB-6009 para aquisio de dados, figura 4.12. Utiliza-se o
Software Labview para o armazenamento dos dados no computador.


Figura 4.12 Mdulo NI USB-6009

Apresenta-se na figura 4.13 a evoluo da temperatura interna do ambiente sob a
atuao do sistema de controle fuzzy PI. Inicialmente a temperatura do ambiente varia
entre 31 e 32 graus. Aos 30 s, estipula-se 25 C como referncia e o sistema de controle
ligado. A temperatura do ambiente se estabiliza no valor de referncia 3 min aps o
sistema de controle iniciar sua operao.

46


Figura 4.13 - Evoluo temporal da temperatura interna do ambiente.




















47

5. CONCLUSES

Neste trabalho desenvolve-se em um microcontrolador da famlia PIC18F4550 um
controlador fuzzy PI para o controle da temperatura interna de um ambiente em escala
reduzida. Por meio de um estudo acerca dos controladores nebulosos foi possvel obter
as leis de controle discretas do controlador fuzzy PI, possibilitando assim uma
implementao pratica.

O microcontrolador utilizado capaz de fazer a leitura do sensor de temperatura e
calcular a potncia a ser entregue ao atuador para que se controle a temperatura do
ambiente. Alm disso, o microcontrolador se comunica com um computador domstico
por uma conexo USB/CDC, possibilitando assim a visualizao em tempo real do
sistema de controle.

O sistema de controle proposto no trabalho apresentou um desempenho satisfatrio,
visto que o mesmo conseguiu conduzir temperatura de referncia em
aproximadamente 3 min.

A IHM (Interface Homem Maquina) para visualizao dos dados no computador uma
aplicao WEB e foi desenvolvida na plataforma HTML/JavaScript. Essa aplicao
possibilita a visualizao em tempo real do sistema de controle de qualquer ponto ligado
a rede.

Alm disso, em virtude dessa aplicao ter suas bases na plataforma Java, pode-se
acompanhar o controle do sistema em qualquer dispositivos, como por exemplo,
smartphones, tablets, visto que os mesmos tem a capacidade de emular aplicaes Java.

Como sugestes para trabalhos futuros propem-se a utilizao de um sistema que
permita no s resfriar o ambiente construdo, mas tambm aquec-lo. Alm disso, a
aplicao WEB desenvolvida no trabalho pode ser hospedada em um servidor na
internet, possibilitando assim que o controle seja acessado e visualizado de qualquer
computador que possua o servio de internet.

48

REFERNCIAS BIBLIOGRFICAS

AMERICAN SOCIETY FOR HEATING, REFRIGERATING AND AIR
CONDITIONING ENGINEERING. Thermal environmental conditions for human
occupancy. ANSI/ASHRAE 55:2004. Atlanta, 2004.

ASTROM, K. J.; HAGGLUND, T. Automatic Tuning of PID Controllers. 1 Edio.
United States of America: Instrument Society of America, 1988.

ASTROM, K. J.; HAGGLUND, H.; WALLENBORG, A. Automatic tuning of digital
controllers with applications to hvac plants. Automatica 29(5), 1993.

AXELSON, J. Parallel port complete: programming, interfacing and using the
PCs parallel printer port. 1996. Disponvel em:
<http://www.lvr.com/parprtib.htm#Chapter1>. Acesso em: 25 de novembro de 2011.

DATASHEET do microcontrolador PIC18F4550 disponvel em
http://ww1.microchip.com/downloads/en/DeviceDoc/39632e.pdf. Acesso em 10 de
novembro de 2011.

DORF, R. C.; BISHOP, R. H. Modern Control Systems. 10 Edio. United States of
America: Pearson Prentice Hall, 2005.

DUMUR, D.; BOUCHER, P.; MURPHY, K. M. Comfort control in residential housing
using predicitve controllers. United States of America: IEEE International
Conference on Control Applications. Hartford, CT, USA, 1997.

FANGER, P. O., Thermal Comfort, Analysis and Application in Environmental
Engineering, McGraw-Hill, New York, 1972. 245 p.

GIVONI, B. Man, climate and architecture. Londres: Elsevier, 1976.

49

GIVONI, B. Confort Climate Analysis and Building Design Guidelines. Energy and
Buildings, n. 18 p. 11/23, 1992.

HEY, H. L. Projeto Reenge - Caderno Didtico de Sistemas de Controle I. 1 ed.
Santa Maria, 1997.

HORENSTEIN, M. N., Microeletrnica circuitos & dispositivos, Rio de Janeiro.
Editora Prentice-Hall do Brasil, 1996

LOURENO, J. Sintonia de Controladores PID. Rio de Janeiro: 1997.

OGATA, K. Engenharia de Controle Moderno. 4 Edio. So Paulo: Prentice Hall,
2003.

OLIVEIRA, I. S. Controle fuzzy PI de temperatura num modelo de edificao em
escala reduzida. 2008. Monografia (Trabalho de Final de Curso em Engenharia de
Controle e Automao). Escola de Minas, Universidade Federal de Ouro Preto, Minas
Gerais, 2008.

OLIVEIRA, G. H. C.; ARAJO, H. X.; COELHO, L. S.; MENDES, N. Using fuzzy
logic in heating control systems. Hawaii, USA: In: Proc. of the 6-th ASME-JSME
Thermal Engineering, Vol1,p 1-6, 2003.

RENTEL-GOMEZ, C.; VELEZ-REYES, M. Decoupled control of temperature and
relative humidity using avariable-air-volume hvac system and non-interacting control.
In: Proc. of the 2001 IEEE International Conference on Control Applications. IEEE.
Mexico City, Mexico. pp. 1147/1151, 2001.

SANDRI, S.; CORREA, C. Lgica Nebulosa. In: ESCOLA DE REDES NEURAIS, 5.,
1999, So Jos dos Campos. Anais... So Jos dos Campos: ITA, 1999, p. c73-c90.

SIMPSON, B. Tomcat Howto, 1 ed. 2007 Disponvel em:
<http://pub.admc.com/howtos/tomcat/tomcat.pdf>. Acesso em: 13 de dez. 2011.
50

SZOKOLAY, S. V. Thermal Design of Buildings. Australia: Raia Education Division,
1987.

TANG, W.; CHEN, G.; LU, R. A modified fuzzy PI controller for a flexible-joint
robot arm with uncertainties. Fuzzy Sets and Systems, Houston, v. 118 , n. 1, p. 109-
119, 2001.

TORRES, F. E.; MARTINS, H. R. Apostila didtica PICMinas: Sistemas
microcontrolados, V. 1. Editora Axoon, 2010.

XAVIER, A. A. P. Condies de conforto trmico para estudantes de 2 grau na
regio de Florianpolis. Florianpolis. 1999. 198 p. Dissertao (Mestrado) -
Faculdade de Engenharia Civil, Universidade Federal de Santa Catarina, Florianpolis,
1999.

XAVIER, A. A. P. Predio de conforto trmico em ambientes internos com
atividade sedentria: Teoria fsica aliada a estudos de campo. 2005. 251 p. Tese
(Doutorado). Faculdade de Engenharia de Produo e Sistemas, Universidade Federal
de Santa Catarina, Florianpolis, 2005.



ANEXO I
CDIGO FONTE DO SOFTWARE DE CONTROLE

Apresenta-se o cdigo fonte, em linguagem C, do controlador fuzzy PI, implementado
no microcontrolador PIC18F4550. Este cdigo foi desenvolvido no compilador
MPLAB IDE V8.60/C18.


/**********************************************************************
********
*
* Monografia Pedro Henrique Sousa Prado
* Professor: Henor Artur de Souza
*
*
*

**********************************************************************
********


**********************************************************************
*******/

/** I N C L U D E S
**********************************************************/
#include <p18F4550.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <adc.h>
#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "usb_config.h"
#include "usb_device.h"
#include "usb.h"
#include "HardwareProfile.h"
#include "usb_function_cdc.h"
#include "my_xlcd.h"
#include <pwm.h>
#include <delays.h>
#include <timers.h>
#include <stdlib.h>




/** CONFIGURATION **************************************************/

#pragma config PLLDIV = 5 // (20 MHz crystal on PICDEM FS USB board)
#pragma config CPUDIV = OSC1_PLL2
#pragma config USBDIV = 2 // Clock source from 96MHz PLL/2
#pragma config FOSC = HSPLL_HS
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config PWRT = OFF
#pragma config BOR = ON
#pragma config BORV = 3
#pragma config VREGEN = ON //USB Voltage Regulator
#pragma config WDT = OFF
#pragma config WDTPS = 32768
#pragma config MCLRE = ON
#pragma config LPT1OSC = OFF
#pragma config PBADEN = OFF
// #pragma config CCP2MX = ON
#pragma config STVREN = ON
#pragma config LVP = OFF
// #pragma config ICPRT = OFF // Dedicated In-Circuit Debug/Programming
#pragma config XINST = OFF // Extended Instruction Set
#pragma config CP0 = OFF
#pragma config CP1 = OFF
// #pragma config CP2 = OFF
// #pragma config CP3 = OFF
#pragma config CPB = OFF
// #pragma config CPD = OFF
#pragma config WRT0 = OFF
#pragma config WRT1 = OFF
// #pragma config WRT2 = OFF
// #pragma config WRT3 = OFF
#pragma config WRTB = OFF // Boot Block Write Protection
#pragma config WRTC = OFF
// #pragma config WRTD = OFF
#pragma config EBTR0 = OFF
#pragma config EBTR1 = OFF
// #pragma config EBTR2 = OFF
// #pragma config EBTR3 = OFF
#pragma config EBTRB = OFF


/** D E F I N E S
************************************************************/

#define LEDAmarelo PORTDbits.RD0
#define LEDVermelho PORTDbits.RD1


#define VDD 5

#define BOTAO_1 PORTEbits.RE1
#define BOTAO_2 PORTEbits.RE2



/** V A R I A V E I S G L O B A I S
****************************************/
// variveis par uso das rotinas de USB
char USB_Out_Buffer[CDC_DATA_OUT_EP_SIZE];
char RS232_Out_Data[CDC_DATA_IN_EP_SIZE];

unsigned char NextUSBOut;
unsigned char NextUSBOut;
unsigned char LastRS232Out; // Number of characters in the buffer
unsigned char RS232cp; // current position within the buffer
unsigned char RS232_Out_Data_Rdy = 0;
USB_HANDLE lastTransmission;
int temp_ref=19;
float y,errodecd,porcentagempwmf;
unsigned int ciclo; // Ciclo de trabalho do PWM2
int le1=27, le2=27,erroint,errodec,porcentagempwm;



/** P R O T O T I P O S P R I V A D O S
***********************************/
static void ConfigSystem (void);
static void InitializeUSBSystem(void);
void ProcessIO(void);
void USBDeviceTasks(void);
void YourHighPriorityISRCode();
void YourLowPriorityISRCode();
void BlinkUSBStatus(void);
void UserInit(void);
void InitializeUSART(void);
void putcUSART(char c);
unsigned char getcUSART ();

//interrupcoes

void HighPriorityISRCode();
void LowPriorityISRCode();

/** F U N C O E S
************************************************************/



/**********************************************************************
********
* Funcao: void main(void)
* Entrada: Nenhuma (void)
* Sada: Nenhuma (void)
* Descrio: Funo principal do programa.
*
* Este pograma envia um pacote de 5 caracteres continuamente para a USB simulada e
* ecoa de volta para a USB tude que ele recebeu dele.
* Ver o cdigo em main(..) e ProcessIO(..)

**********************************************************************
*******/
void main(void)
{
unsigned long i,k;
char example_string[5],bufferint[2],bufferdec[2],potpwm[3],tempreff[2];
unsigned char pacote[11];

int Num_CAD_bin = 0;
float Num_CAD_volts = 0.0;
float Num_CAD_graus = 0;
float resolucao = 5/1023.0;
int b, conversaoh, conversaol,x,decPart ,intPart;
double decPartd;



ConfigSystem ();
InitializeUSBSystem();
OpenPWM2(254); // PWM period =[(period ) + 1] x 4 x TOSC x TMR2=
0,34ms



#if defined(USB_INTERRUPT)
USBDeviceAttach();
#endif

k=0;

while (1){
// APENAS TESTE: Cria um delay -----
for(i=0;i<30000;i++){
Nop();
}

#if defined(USB_POLLING)
// Check bus status and service USB interrupts.


USBDeviceTasks(); // Interrupt or polling method. If using polling, must call
// this function periodically. This function will take care
// of processing and responding to SETUP transactions
// (such as during the enumeration process when you first
// plug in). USB hosts require that USB devices should
accept
// and process SETUP packets in a timely fashion.
Therefore,
// when using polling, this function should be called
// frequently (such as once about every 100
microseconds) at any
// time that a SETUP packet might reasonably be
expected to
// be sent by the host to your device. In most cases, the
// USBDeviceTasks() function does not take very long to
// execute (~50 instruction cycles) before it returns.
#endif


// Application-specific tasks.
// Application related code may be added here, or in the ProcessIO()
function.




if (BOTAO_1) {
temp_ref=temp_ref+1;
if(temp_ref>=31)
{
temp_ref=18;
}
}





// Temperatura

SetDDRamAddr(0x00);
putrsXLCD("TEMP:");
SetChanADC(ADC_CH0);
for(i = 0; i < 5; i++)
{
Delay100TCYx(1);
if(!BusyADC())
{
// L o valor convertido e armazena na varivel


Num_CAD_bin=ReadADC();
// Inicia a nova Converso
ConvertADC();
}
}

Num_CAD_volts = Num_CAD_bin*resolucao;
Num_CAD_graus = Num_CAD_volts*100;
y=Num_CAD_graus;

// Num_CAD_graus = Num_CAD_volts*100;
// y=Num_CAD_graus-50;


// CONVERTENDO Y FLOAT PARA INTEIRO E JOGANDO PARA LCD

intPart= (int)y;
decPartd=y-intPart;
decPartd=decPartd*100;
decPart=(int)decPartd;
SetDDRamAddr(0x05);
putIntXLCD(intPart);
SetDDRamAddr(0x07);
putrsXLCD(".");
SetDDRamAddr(0x08);
putIntXLCD(decPart);
SetDDRamAddr(0x40);
putrsXLCD("P:");

// Calcula % do ciclo para enviar para software

porcentagempwmf=ciclo-21;
porcentagempwmf=porcentagempwmf/10;
porcentagempwm=(int)porcentagempwmf;


if (porcentagempwm<=70) {
porcentagempwm=0;
SetDDRamAddr(0x42);
putrsXLCD("00");
SetDDRamAddr(0x44);
putrsXLCD("%");
}
else
{
SetDDRamAddr(0x42);
putIntXLCD(porcentagempwm); // COLOCAR O CICLO EM %
SetDDRamAddr(0x44);
putrsXLCD("%");


}




SetDDRamAddr(0x46);
putrsXLCD("Tf:");
SetDDRamAddr(0x49);
putIntXLCD(temp_ref);

// Fazendo o buffer para jogar o char para a porta serial

itoa(intPart,bufferint);
itoa(decPart,bufferdec);

itoa(porcentagempwm,potpwm);

itoa(temp_ref,tempreff);


pacote[0] = 0xFF ; // STX
pacote[1] = 11 ; // MSG_SIZE=

// dados (incrementando a variavel k de 0 at 120)
pacote[2] = bufferint[0]; // DATA_HIGH=0x00
pacote[3] = bufferint[1]; // DATA_LOW= k
pacote[4] = bufferdec[0];
pacote[5] = bufferdec[1];

pacote[6] =potpwm[0];
pacote[7] =potpwm[1];
pacote[8] =tempreff[0];

pacote[9] =tempreff[1];
pacote[10] =0xEE ; // ETX


k++;
if(k>120)
k=0;

if(mUSBUSARTIsTxTrfReady()){
mUSBUSARTTxRam((unsigned char*)pacote,12); // envia o
buffer
}
// ---------------------------------

ProcessIO();



}

}


/**********************************************************************
********
* Funcao: static void ConfiguraSistema(void)
* Entrada: Nenhuma (void)
* Sada: Nenhuma (void)
* Descrio: ConfiguraSistema a rotina de configurao principal do PIC.
* Seu objetivo configurar as portas de I/O e os
perifricos
* do microcontrolador para que os mesmos
trabalhem da maneira
* desejada no projeto.
*

**********************************************************************
*******/
static void ConfigSystem (void)
{
// Configura seu sistema aqui!!!
// Lembre-se de organizar entradas separada das saidas e fazer uma descrio da
configurao
// Ex:
// Configura LED's do KitPIC: saida digital
// TRISxxbits.TRISxx=0; // PINxx - Rxx: saida digital -
LED_VERDE
// TRISxxbits.TRISxx=0; // PINxx - Rxx: saida digital -
LED_VERMELHO
//
// Configura Botes do KitPIC: entradas digitais
// TRISxxbits.TRISxx=1; // PINxx - Rxx: entrada digital - BOTAO_1
// TRISxxbits.TRISxx=1; // PINxx - Rxx: entrada digital - BOTAO_2

ADCON1 |= 0x0F; // configura todas as portas como digitais
// Depois do reset, RE1 e RE2 sao
configuradas como entrada analogicas
// por default. (pag 125 datasheet)
// para informaoes sobre ADCON1
: pag 262 datasheet.

ADCON1 |= 0x0F; // configura todas as portas como digitais

//Configura o conversor AD
OpenADC(
//Parmetro Config
ADC_FOSC_64 &


ADC_RIGHT_JUST &
ADC_2_TAD,
ADC_CH0 &
ADC_INT_OFF &
ADC_REF_VDD_VSS,
ADC_6ANA );

OpenXLCD(); // Inicializa o LCD

// CONFIGURAO PWM

TRISC=0b11111001; // Set channel C1 and C2 as PWM output.
LATC= 0x00; // Initialize the PORTC.

OpenTimer2(T2_PS_1_16 & TIMER_INT_OFF); // Timer2 is used for the time
base of the PWM. set timer2 before PWM works.




TRISD = 0x00; // Coloca toda a porta D como sada.

LEDAmarelo =0; // apaga os LEDs
LEDVermelho =0;

// configura o TMR0 para clock interno e prescaler dividindo por 64
T0CONbits.T0CS = 0; // clk interno
T0CONbits.PSA = 0; // habilita prescaller

// coloca prescaler em 256
T0CONbits.T0PS0 = 1;
T0CONbits.T0PS1 = 1;
T0CONbits.T0PS2 = 1;

T0CONbits.T08BIT=0; // configura para 16 bits

// habilita interrupes
INTCON2bits.TMR0IP=0; // Interrupt priority bit set to 0 - low priority.
INTCONbits.TMR0IE = 1; // enable Timer 0 interrupts
INTCONbits.PEIE = 1; // enable peripheral interrupts
T0CONbits.TMR0ON=1; // liga o timer
INTCONbits.TMR0IF = 0; // limpa o flag de interrupao
INTCONbits.GIE = 1; // enable all interrupts


}//end ConfiguraSistema

/**********************************************************************
********


* Funcao: void Tratamento_High_Interrupt(void)
* Entrada: Nenhuma (void)
* Sada: Nenhuma (void)
* Descrio: Funo de tratamento das interrupes de ALTA prioridade
* Nessa funo deve-se lembrar de fazer a seguinte lista:
* 1- verificar qual foi a causa da interrupo,
comparando
* os flags de cada tipo de interrupo.
* 2- tratar a interrupo selecionada.
* 3- limpar o flag que causou a interrupo!!!
Importante
* para garantir que no ocorrer uma chamada indesejada ao
sair
* do tratamento da interrupo.
*
* Ao sair dessa funo usado o retorno do tipo "retfie
fast",
* pois esta funo declarada como ALTA prioridade com a
diretiva
* #pragma interrupt
*

**********************************************************************
*******/
// ATENO NA SINTAXE de declarao com #pragma interrupt = Alta prioridade
#pragma interrupt Tratamento_High_Interrupt
void Tratamento_High_Interrupt(void)
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
#if defined(USB_INTERRUPT)
USBDeviceTasks();
#endif

}// end Tratamento_High_Interrupt

/**********************************************************************
********
* Funcao: void Tratamento_High_Interrupt(void)
* Entrada: Nenhuma (void)
* Sada: Nenhuma (void)
* Descrio: Funo de tratamento das interrupes de BAIXA prioridade
* Nessa funo deve-se lembrar de fazer a seguinte lista:
* 1- verificar qual foi a causa da interrupo,
comparando
* os flags de cada tipo de interrupo.
* 2- tratar a interrupo selecionada.


* 3- limpar o flag que causou a interrupo!!!
Importante
* para garantir que no ocorrer uma chamada indesejada ao
sair
* do tratamento da interrupo.
*
* Ao sair dessa funo usado o retorno do tipo "retfie",
* pois esta funo declarada como BAIXA prioridade com
a diretiva
* #pragma interruptlow
*

**********************************************************************
*******/
// ATENO NA SINTAXE de declarao com #pragma interruptlow = Baixa
prioridade
#pragma interruptlow Tratamento_Low_Interrupt
void Tratamento_Low_Interrupt(void)
{
float erro; // Erro da temperatura
static float erro_anterior; // Erro anterior da temperatura
static float out_fuzzy_anterior; // Sada anterior do controlador Fuzzy PI
unsigned int control_on = 1; // Varivel que diz o estado do sistema de controle


// *** Ganhos do controlador Fuzzy PI ***
int ciclotint;
const int Ki = 1;
const int K = 10;
const int Ku = 40; // Ganho de controle incremental
float out_fuzzy; // Sada do controlador Fuzzy PI

float taxa; // Taxa em que o erro varia
float abs_taxa; // Mdulo da taxa
float abs_erro_ant; // Mdulo do erro anterior
float out_inc_fuzzy; // Incremento na sada do controlador Fuzzy PI

erro = temp_ref - y; // Calcula o erro
erroint= (int)erro;
errodecd=erro-erroint;
errodecd=errodecd*100;
errodec=(int)errodecd;

if (erro >= 0.5) {
control_on = 0; // Desliga o sistema de controle
ciclo=0;
SetDCPWM2(ciclo); // Desliga o cooler
}



if (control_on) {

taxa = erro - erro_anterior; // Calcula a derivada do erro
erro_anterior = erro;

abs_erro_ant = fabs(erro_anterior); // Calcula o mdulo do erro
abs_taxa = fabs(taxa); // Calcula o mdulo da derivada do erro

// *** Calcula a sada da base de regras do controlador nebuloso ***
// *** Regies IC1, IC2, IC5 e IC6 ***
if ((K * abs_taxa <= Ki * abs_erro_ant) && (Ki * abs_erro_ant <= 1))
out_inc_fuzzy = (Ki * erro + K * taxa) / (2 * (2 - Ki * abs_erro_ant));


// *** Regies IC3, IC4, IC7 e IC8 ***
else if ((Ki * abs_erro_ant <= K * abs_taxa) && (K * abs_taxa <= 1))
out_inc_fuzzy = (Ki * erro + K * taxa) / (2 * (2 - K * abs_taxa));

// *** Regies IC9 e IC10 ***
else if ((Ki * erro > 1) && (K * abs_taxa < 1))
out_inc_fuzzy = 0.5 * (K * taxa + 1);

// *** Regies IC11 e IC12 ***
else if ((K * taxa > 1) && (Ki * abs_erro_ant < 1))
out_inc_fuzzy = 0.5 * (Ki * erro + 1);

// *** Regies IC13 e IC14 ***
else if ((Ki * erro < -1) && (K * abs_taxa < 1))
out_inc_fuzzy = 0.5 * (K * taxa - 1);

// *** Regies IC15 e IC16 ***
else if ((K * taxa < -1) && (Ki * abs_erro_ant < 1))
out_inc_fuzzy = 0.5 * (Ki * erro - 1);

// *** Regio IC17 ***
else if ((Ki * erro > 1) && (K * taxa > 1))
out_inc_fuzzy = 1;

// *** Regies IC19 ***
else if ((Ki * erro < -1) && (K * taxa < -1))
out_inc_fuzzy = -1;

// *** Regies IC18 e IC20 ***
else out_inc_fuzzy = 0;

// *** Calcula a sada do controlador fuzzy PI ***
out_fuzzy = out_fuzzy_anterior + Ku * out_inc_fuzzy;

ciclo = (int)out_fuzzy; // Seta o ciclo de trabalho do cooler



if (ciclo<<0) {
ciclo=ciclo*(-1);
}



if (ciclo > 1020) ciclo = 1020; // Saturao no mximo
if (ciclo < 255) ciclo = 255; // Saturao no mnimo


out_fuzzy = ciclo;
SetDCPWM2(ciclo);

out_fuzzy_anterior = -out_fuzzy;


}



TMR0L = 0xB4; // recarrega o timer
TMR0H = 0xB3;

LEDVermelho = !LEDVermelho;

LEDAmarelo = !LEDAmarelo; // apaga os LEDs

INTCONbits.TMR0IF = 0; // limpa o flag de interrupao



}//end Tratamento_Low_Interrupt


/** V E C T O R R E M A P P I N G
******************************************/
// Seo necessria para informar ao compilador C18 onde so os novos endereos
//da memria de programa que ele deve alocar as rotinas de tratamento do "reset"
//do microcontrolador e das rotinas de tratamento de interrupo.
//
//ATENO: COPIAR ESTA SEO DO CODIGO PARA TODO ARQUIVO
"main.c" DOS PROJETOS QUE
//UTILIZAM O BOOTLOADER PARA GRAVAO IN-CIRCUIT atravs do
BOOTLoader.

// Alocao da funo de tratamento das interrupes de ALTA prioridade
// no endereo 0x1008 da memria de programa.
//


#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = 0x001008
void _high_ISR (void)
{
_asm goto Tratamento_High_Interrupt _endasm
}

// Alocao da funo de tratamento das interrupes de BAIXA prioridade
// no endereo 0x1018 da memria de programa
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = 0x001018
void _low_ISR (void)
{
_asm goto Tratamento_Low_Interrupt _endasm
}

#pragma code // Diretiva que retorna a alocao dos endereos
// da memria de programa para seus valores padro

/** V E C T O R R E M A P P I N G
******************************************/
// Rotina necessria para o compilador C18 saber onde o incio do vetor de
// "reset".
// Copiar na ntegra esta parte do cdigo dentro do arquivo "main.c" de TODO
// projeto usado com o Bootloader no PIC.

// prottipo usado pelo compilador C18
extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = 0x1000
void _reset (void)
{
_asm goto _startup _endasm;
}
#pragma code

/**Rotinas da
USB***************************************************************/

/********************************************************************
* Function: static void InitializeSystem(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: InitializeSystem is a centralize initialization
* routine. All required USB initialization routines


* are called from here.
*
* User application initialization routine should
* also be called from here.
*
* Note: None
*******************************************************************/
static void InitializeUSBSystem(void)
{
#if (defined(__18CXX) & !defined(PIC18F87J50_PIM))
ADCON1 |= 0x0F; // Default all pins to digital
#elif defined(__C30__)
AD1PCFGL = 0xFFFF;
#elif defined(__C32__)
AD1PCFG = 0xFFFF;
#endif

#if defined(PIC18F87J50_PIM) || defined(PIC18F46J50_PIM)
//On the PIC18F87J50 Family of USB microcontrollers, the PLL will not power
up and be enabled
//by default, even if a PLL enabled oscillator configuration is selected (such as
HS+PLL).
//This allows the device to power up at a lower initial operating frequency,
which can be
//advantageous when powered from a source which is not gauranteed to be
adequate for 48MHz
//operation. On these devices, user firmware needs to manually set the
OSCTUNE<PLLEN> bit to
//power up the PLL.
{
unsigned int pll_startup_counter = 600;
OSCTUNEbits.PLLEN = 1; //Enable the PLL and wait 2+ms until the PLL locks
before enabling USB module
while(pll_startup_counter--);
}
//Device switches over automatically to PLL output after PLL is locked and ready.
#endif

#if defined(PIC18F87J50_PIM)
//Configure all I/O pins to use digital input buffers. The PIC18F87J50 Family
devices
//use the ANCONx registers to control this, which is different from other devices
which
//use the ADCON1 register for this purpose.
WDTCONbits.ADSHR = 1; // Select alternate SFR location to
access ANCONx registers
ANCON0 = 0xFF; // Default all pins to digital
ANCON1 = 0xFF; // Default all pins to digital
WDTCONbits.ADSHR = 0; // Select normal SFR locations


#endif

#if defined(PIC18F46J50_PIM)
//Configure all I/O pins to use digital input buffers. The PIC18F87J50 Family
devices
//use the ANCONx registers to control this, which is different from other devices
which
//use the ADCON1 register for this purpose.
ANCON0 = 0xFF; // Default all pins to digital
ANCON1 = 0xFF; // Default all pins to digital
#endif

#if defined(PIC24FJ64GB004_PIM)
//On the PIC24FJ64GB004 Family of USB microcontrollers, the PLL will not
power up and be enabled
//by default, even if a PLL enabled oscillator configuration is selected (such as
HS+PLL).
//This allows the device to power up at a lower initial operating frequency,
which can be
//advantageous when powered from a source which is not gauranteed to be
adequate for 32MHz
//operation. On these devices, user firmware needs to manually set the
CLKDIV<PLLEN> bit to
//power up the PLL.
{
unsigned int pll_startup_counter = 600;
CLKDIVbits.PLLEN = 1;
while(pll_startup_counter--);
}

//Device switches over automatically to PLL output after PLL is locked and ready.
#endif


// The USB specifications require that USB peripheral devices must never source
// current onto the Vbus pin. Additionally, USB peripherals should not source
// current on D+ or D- when the host/hub is not actively powering the Vbus line.
// When designing a self powered (as opposed to bus powered) USB peripheral
// device, the firmware should make sure not to turn on the USB module and D+
// or D- pull up resistor unless Vbus is actively powered. Therefore, the
// firmware needs some means to detect when Vbus is being powered by the host.
// A 5V tolerant I/O pin can be connected to Vbus (through a resistor), and
// can be used to detect when Vbus is high (host actively powering), or low
// (host is shut down or otherwise not supplying power). The USB firmware
// can then periodically poll this I/O pin to know when it is okay to turn on
// the USB module/D+/D- pull up resistor. When designing a purely bus powered
// peripheral device, it is not possible to source current on D+ or D- when the
// host is not actively providing power on Vbus. Therefore, implementing this
// bus sense feature is optional. This firmware can be made to use this bus


// sense feature by making sure "USE_USB_BUS_SENSE_IO" has been defined
in the
// HardwareProfile.h file.
#if defined(USE_USB_BUS_SENSE_IO)
tris_usb_bus_sense = INPUT_PIN; // See HardwareProfile.h
#endif

// If the host PC sends a GetStatus (device) request, the firmware must respond
// and let the host know if the USB peripheral device is currently bus powered
// or self powered. See chapter 9 in the official USB specifications for details
// regarding this request. If the peripheral device is capable of being both
// self and bus powered, it should not return a hard coded value for this request.
// Instead, firmware should check if it is currently self or bus powered, and
// respond accordingly. If the hardware has been configured like demonstrated
// on the PICDEM FS USB Demo Board, an I/O pin can be polled to determine the
// currently selected power source. On the PICDEM FS USB Demo Board, "RA2"
// is used for this purpose. If using this feature, make sure
"USE_SELF_POWER_SENSE_IO"
// has been defined in HardwareProfile.h, and that an appropriate I/O pin has been
mapped
// to it in HardwareProfile.h.
#if defined(USE_SELF_POWER_SENSE_IO)
tris_self_power = INPUT_PIN; // See HardwareProfile.h
#endif

UserInit();

USBDeviceInit(); //usb_device.c. Initializes USB module SFRs and firmware
//variables to known states.
}//end InitializeSystem



/**********************************************************************
********
* Function: void UserInit(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This routine should take care of all of the demo code
* initialization that is required.
*
* Note:


*

**********************************************************************
*******/
void UserInit(void)
{
unsigned char i;
InitializeUSART();

// Initialize the arrays
for (i=0; i<sizeof(USB_Out_Buffer); i++)
{
USB_Out_Buffer[i] = 0;
}

NextUSBOut = 0;
LastRS232Out = 0;
lastTransmission = 0;

mInitAllLEDs();
}//end UserInit

/**********************************************************************
********
* Function: void InitializeUSART(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This routine initializes the UART to 19200
*
* Note:
*

**********************************************************************
*******/
void InitializeUSART(void)
{
#if defined(__18CXX)
unsigned char c;
#if defined(__18F14K50)
//ANSELHbits.ANS11 = 0; // Make RB5 digital so USART can use pin
for Rx
ANSELH = 0;


#ifndef BAUDCON
#define BAUDCON BAUDCTL
#endif
#endif
UART_TRISRx=1; // RX
UART_TRISTx=0; // TX
TXSTA = 0x24; // TX enable BRGH=1
RCSTA = 0x90; // Single Character RX
SPBRG = 0x71;
SPBRGH = 0x02; // 0x0271 for 48MHz -> 19200 baud
BAUDCON = 0x08; // BRG16 = 1
c = RCREG; // read
#endif

#if defined(__C30__)
#if defined( __PIC24FJ256GB110__ )
// PPS - Configure U2RX - put on pin 49 (RP10)
RPINR19bits.U2RXR = 10;

// PPS - Configure U2TX - put on pin 50 (RP17)
RPOR8bits.RP17R = 5;
#elif defined(__PIC24FJ64GB004__)
// PPS - Configure U2RX - put on RC3/pin 36 (RP19)
RPINR19bits.U2RXR = 19;

// PPS - Configure U2TX - put on RC9/pin 5 (RP25)
RPOR12bits.RP25R = 5;
#else
#error Verify that any required PPS is done here.
#endif

UART2Init();
#endif

#if defined(__C32__)
UART2Init();
#endif

}//end InitializeUSART

#if defined(__18CXX)
#define mDataRdyUSART() PIR1bits.RCIF
#define mTxRdyUSART() TXSTAbits.TRMT
#elif defined(__C30__) || defined(__C32__)
#define mDataRdyUSART() UART2IsPressed()
#define mTxRdyUSART() U2STAbits.TRMT
#endif



/**********************************************************************
********
* Function: void putcUSART(char c)
*
* PreCondition: None
*
* Input: char c - character to print to the UART
*
* Output: None
*
* Side Effects: None
*
* Overview: Print the input character to the UART
*
* Note:
*

**********************************************************************
*******/
void putcUSART(char c)
{
#if defined(__18CXX)
TXREG = c;
#else
UART2PutChar(c);
#endif
}


/**********************************************************************
********
* Function: void mySetLineCodingHandler(void)
*
* PreCondition: USB_CDC_SET_LINE_CODING_HANDLER is defined
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function gets called when a SetLineCoding command
* is sent on the bus. This function will evaluate the request
* and determine if the application should update the baudrate
* or not.
*
* Note:
*



**********************************************************************
*******/
#if defined(USB_CDC_SET_LINE_CODING_HANDLER)
void mySetLineCodingHandler(void)
{
//If the request is not in a valid range
if(cdc_notice.GetLineCoding.dwDTERate.Val > 115200)
{
//NOTE: There are two ways that an unsupported baud rate could be
//handled. The first is just to ignore the request and don't change
//the values. That is what is currently implemented in this function.
//The second possible method is to stall the STATUS stage of the request.
//STALLing the STATUS stage will cause an exception to be thrown in the
//requesting application. Some programs, like HyperTerminal, handle the
//exception properly and give a pop-up box indicating that the request
//settings are not valid. Any application that does not handle the
//exception correctly will likely crash when this requiest fails. For
//the sake of example the code required to STALL the status stage of the
//request is provided below. It has been left out so that this demo
//does not cause applications without the required exception handling
//to crash.
//---------------------------------------
//USBStallEndpoint(0,1);
}
else
{
DWORD_VAL dwBaud;

//Update the baudrate info in the CDC driver
CDCSetBaudRate(cdc_notice.GetLineCoding.dwDTERate.Val);

//Update the baudrate of the UART
#if defined(__18CXX)
dwBaud.Val = (GetSystemClock()/4)/line_coding.dwDTERate.Val-1;
SPBRG = dwBaud.v[0];
SPBRGH = dwBaud.v[1];
#elif defined(__C30__)
dwBaud.Val =
(((GetPeripheralClock()/2)+(BRG_DIV2/2*line_coding.dwDTERate.Val))/BRG_DIV2
/line_coding.dwDTERate.Val-1);
U2BRG = dwBaud.Val;
#elif defined(__C32__)
U2BRG =
((GetPeripheralClock()+(BRG_DIV2/2*line_coding.dwDTERate.Val))/BRG_DIV2/lin
e_coding.dwDTERate.Val-1);
//U2MODE = 0;
U2MODEbits.BRGH = BRGH2;
//U2STA = 0;


#endif
}
}
#endif

/**********************************************************************
********
* Function: void putcUSART(char c)
*
* PreCondition: None
*
* Input: None
*
* Output: unsigned char c - character to received on the UART
*
* Side Effects: None
*
* Overview: Print the input character to the UART
*
* Note:
*

**********************************************************************
*******/
unsigned char getcUSART ()
{
char c;

#if defined(__18CXX)

if (RCSTAbits.OERR) // in case of overrun error
{ // we should never see an overrun error, but if we do,
RCSTAbits.CREN = 0; // reset the port
c = RCREG;
RCSTAbits.CREN = 1; // and keep going.
}
else
c = RCREG;
// not necessary. EUSART auto clears the flag when RCREG is cleared
// PIR1bits.RCIF = 0; // clear Flag

#endif

#if defined(__C30__) || defined(__C32__)
c = UART2GetChar();
#endif

return c;
}



/********************************************************************
* Function: void ProcessIO(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is a place holder for other user
* routines. It is a mixture of both USB and
* non-USB tasks.
*
* Note: None
*******************************************************************/
//rom char example_string[] = {65,66,67};

void ProcessIO(void)
{
//char example_string[3];

//Blink the LEDs according to the USB device status
BlinkUSBStatus();
// User Application USB tasks
if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1)) return;

if (RS232_Out_Data_Rdy == 0) // only check for new USB buffer if the old
RS232 buffer is
{ // empty. This will cause
additional USB packets to be NAK'd
LastRS232Out = getsUSBUSART(RS232_Out_Data,64); //until the
buffer is free.

if(LastRS232Out > 0)
{
RS232_Out_Data_Rdy = 1; // signal buffer full
RS232cp = 0; // Reset the current position
}
}

if(RS232_Out_Data_Rdy && mTxRdyUSART())
{
putcUSART(RS232_Out_Data[RS232cp]);
++RS232cp;
if (RS232cp == LastRS232Out)
RS232_Out_Data_Rdy = 0;



// teste ecoa o que foi recebido pelo PIC!!
if(mUSBUSARTIsTxTrfReady()){
mUSBUSARTTxRam((unsigned
char*)&RS232_Out_Data[RS232cp],1); // envia o buffer
}
//teste

}

if(mDataRdyUSART())
{
USB_Out_Buffer[NextUSBOut] = getcUSART();
++NextUSBOut;
USB_Out_Buffer[NextUSBOut] = 0;
}

if((USBUSARTIsTxTrfReady()) && (NextUSBOut > 0))
{
putUSBUSART(&USB_Out_Buffer[0], NextUSBOut);
NextUSBOut = 0;
}

CDCTxService();
} //end ProcessIO

/********************************************************************
* Function: void BlinkUSBStatus(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: BlinkUSBStatus turns on and off LEDs
* corresponding to the USB device state.
*
* Note: mLED macros can be found in HardwareProfile.h
* USBDeviceState is declared and updated in
* usb_device.c.
*******************************************************************/
void BlinkUSBStatus(void)
{
static WORD led_count=0;

if(led_count == 0)led_count = 10000U;


led_count--;

#define mLED_Both_Off() {mLED_1_Off();mLED_2_Off();}
#define mLED_Both_On() {mLED_1_On();mLED_2_On();}
#define mLED_Only_1_On() {mLED_1_On();mLED_2_Off();}
#define mLED_Only_2_On() {mLED_1_Off();mLED_2_On();}

if(USBSuspendControl == 1)
{
if(led_count==0)
{
mLED_1_Toggle();
if(mGetLED_1())
{
mLED_2_On();
}
else
{
mLED_2_Off();
}
}//end if
}
else
{
if(USBDeviceState == DETACHED_STATE)
{
mLED_Both_Off();
}
else if(USBDeviceState == ATTACHED_STATE)
{
mLED_Both_On();
}
else if(USBDeviceState == POWERED_STATE)
{
mLED_Only_1_On();
}
else if(USBDeviceState == DEFAULT_STATE)
{
mLED_Only_2_On();
}
else if(USBDeviceState == ADDRESS_STATE)
{
if(led_count == 0)
{
mLED_1_Toggle();
mLED_2_Off();
}//end if
}
else if(USBDeviceState == CONFIGURED_STATE)


{
if(led_count==0)
{
mLED_1_Toggle();
if(mGetLED_1())
{
mLED_2_Off();
}
else
{
mLED_2_On();
}
}//end if
}//end if(...)
}//end if(UCONbits.SUSPND...)

}//end BlinkUSBStatus


//
**********************************************************************
********************************
// ************** USB Callback Functions
****************************************************************
//
**********************************************************************
********************************
// The USB firmware stack will call the callback functions USBCBxxx() in response to
certain USB related
// events. For example, if the host PC is powering down, it will stop sending out Start of
Frame (SOF)
// packets to your device. In response to this, all USB devices are supposed to decrease
their power
// consumption from the USB Vbus to <2.5mA each. The USB module detects this
condition (which according
// to the USB specifications is 3+ms of no bus activity/SOF packets) and then calls the
USBCBSuspend()
// function. You should modify these callback functions to take appropriate actions for
each of these
// conditions. For example, in the USBCBSuspend(), you may wish to add code that
will decrease power
// consumption from Vbus to <2.5mA (such as by clock switching, turning off LEDs,
putting the
// microcontroller to sleep, etc.). Then, in the USBCBWakeFromSuspend() function,
you may then wish to
// add code that undoes the power saving things done in the USBCBSuspend() function.

// The USBCBSendResume() function is special, in that the USB stack will not
automatically call this


// function. This function is meant to be called from the application firmware instead.
See the
// additional comments near the function.

/**********************************************************************
********
* Function: void USBCBSuspend(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: Call back that is invoked when a USB suspend is detected
*
* Note: None

**********************************************************************
*******/
void USBCBSuspend(void)
{
//Example power saving code. Insert appropriate code here for the desired
//application behavior. If the microcontroller will be put to sleep, a
//process similar to that shown below may be used:

//ConfigureIOPinsForLowPower();
//SaveStateOfAllInterruptEnableBits();
//DisableAllInterruptEnableBits();
//EnableOnlyTheInterruptsWhichWillBeUsedToWakeTheMicro();
//should enable at least USBActivityIF as a wake source
//Sleep();
//RestoreStateOfAllPreviouslySavedInterruptEnableBits(); //Preferrably, this
should be done in the USBCBWakeFromSuspend() function instead.
//RestoreIOPinsToNormal();
//Preferrably, this should be done in the USBCBWakeFromSuspend() function
instead.

//IMPORTANT NOTE: Do not clear the USBActivityIF (ACTVIF) bit here.
This bit is
//cleared inside the usb_device.c file. Clearing USBActivityIF here will cause
//things to not work as intended.


#if defined(__C30__)
#if 0
U1EIR = 0xFFFF;


U1IR = 0xFFFF;
U1OTGIR = 0xFFFF;
IFS5bits.USB1IF = 0;
IEC5bits.USB1IE = 1;
U1OTGIEbits.ACTVIE = 1;
U1OTGIRbits.ACTVIF = 1;
Sleep();
#endif
#endif
}


/**********************************************************************
********
* Function: void _USB1Interrupt(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is called when the USB interrupt bit is set
* In this example the interrupt is only used when the
device
* goes to sleep when it receives a USB suspend
command
*
* Note: None

**********************************************************************
*******/
#if 0
void __attribute__ ((interrupt)) _USB1Interrupt(void)
{
#if !defined(self_powered)
if(U1OTGIRbits.ACTVIF)
{
IEC5bits.USB1IE = 0;
U1OTGIEbits.ACTVIE = 0;
IFS5bits.USB1IF = 0;

//USBClearInterruptFlag(USBActivityIFReg,USBActivityIFBitNum);
USBClearInterruptFlag(USBIdleIFReg,USBIdleIFBitNum);
//USBSuspendControl = 0;
}
#endif


}
#endif

/**********************************************************************
********
* Function: void USBCBWakeFromSuspend(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: The host may put USB peripheral devices in low power
* suspend mode (by "sending" 3+ms of idle). Once
in suspend
* mode, the host may wake the device back up by
sending non-
* idle state signalling.
*
* This call back is invoked when a wakeup from
USB suspend
* is detected.
*
* Note: None

**********************************************************************
*******/
void USBCBWakeFromSuspend(void)
{
// If clock switching or other power savings measures were taken when
// executing the USBCBSuspend() function, now would be a good time to
// switch back to normal full power run mode conditions. The host allows
// a few milliseconds of wakeup time, after which the device must be
// fully back to normal, and capable of receiving and processing USB
// packets. In order to do this, the USB module must receive proper
// clocking (IE: 48MHz clock must be available to SIE for full speed USB
// operation).
}

/********************************************************************
* Function: void USBCB_SOF_Handler(void)
*
* PreCondition: None
*
* Input: None
*


* Output: None
*
* Side Effects: None
*
* Overview: The USB host sends out a SOF packet to full-speed
* devices every 1 ms. This interrupt may be useful
* for isochronous pipes. End designers should
* implement callback routine as necessary.
*
* Note: None
*******************************************************************/
void USBCB_SOF_Handler(void)
{
// No need to clear UIRbits.SOFIF to 0 here.
// Callback caller is already doing that.
}

/*******************************************************************
* Function: void USBCBErrorHandler(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: The purpose of this callback is mainly for
* debugging during development. Check UEIR to see
* which error causes the interrupt.
*
* Note: None
*******************************************************************/
void USBCBErrorHandler(void)
{
// No need to clear UEIR to 0 here.
// Callback caller is already doing that.

// Typically, user firmware does not need to do anything special
// if a USB error occurs. For example, if the host sends an OUT
// packet to your device, but the packet gets corrupted (ex:
// because of a bad connection, or the user unplugs the
// USB cable during the transmission) this will typically set
// one or more USB error interrupt flags. Nothing specific
// needs to be done however, since the SIE will automatically
// send a "NAK" packet to the host. In response to this, the
// host will normally retry to send the packet again, and no
// data loss occurs. The system will typically recover


// automatically, without the need for application firmware
// intervention.

// Nevertheless, this callback function is provided, such as
// for debugging purposes.
}


/*******************************************************************
* Function: void USBCBCheckOtherReq(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: When SETUP packets arrive from the host, some
* firmware must process the request and respond
* appropriately to fulfill the request. Some of
* the SETUP packets will be for standard
* USB "chapter 9" (as in, fulfilling chapter 9 of
* the official USB specifications) requests, while
* others may be specific to the USB device class
* that is being implemented. For example, a HID
* class device needs to be able to respond to
* "GET REPORT" type of requests. This
* is not a standard USB chapter 9 request, and
* therefore not handled by usb_device.c. Instead
* this request should be handled by class specific
* firmware, such as that contained in
usb_function_hid.c.
*
* Note: None
*******************************************************************/
void USBCBCheckOtherReq(void)
{
USBCheckCDCRequest();
}//end


/*******************************************************************
* Function: void USBCBStdSetDscHandler(void)
*
* PreCondition: None
*
* Input: None


*
* Output: None
*
* Side Effects: None
*
* Overview: The USBCBStdSetDscHandler() callback function is
* called when a SETUP, bRequest:
SET_DESCRIPTOR request
* arrives. Typically SET_DESCRIPTOR requests
are
* not used in most applications, and it is
* optional to support this type of request.
*
* Note: None
*******************************************************************/
void USBCBStdSetDscHandler(void)
{
// Must claim session ownership if supporting this request
}//end


/*******************************************************************
* Function: void USBCBInitEP(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is called when the device becomes
* initialized, which occurs after the host sends a
* SET_CONFIGURATION (wValue not = 0)
request. This
* callback function should initialize the endpoints
* for the device's usage according to the current
* configuration.
*
* Note: None
*******************************************************************/
void USBCBInitEP(void)
{
CDCInitEP();
}

/********************************************************************
* Function: void USBCBSendResume(void)


*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: The USB specifications allow some types of USB
* peripheral devices to wake up a host PC (such
* as if it is in a low power suspend to RAM state).
* This can be a very useful feature in some
* USB applications, such as an Infrared remote
* control receiver. If a user presses the "power"
* button on a remote control, it is nice that the
* IR receiver can detect this signalling, and then
* send a USB "command" to the PC to wake up.
*
* The USBCBSendResume() "callback" function is
used
* to send this special USB signalling which wakes
* up the PC. This function may be called by
* application firmware to wake up the PC. This
* function should only be called when:
*
* 1. The USB driver used on the host PC supports
* the remote wakeup capability.
* 2. The USB configuration descriptor indicates
* the device is remote wakeup capable in the
* bmAttributes field.
* 3. The USB host PC is currently sleeping,
* and has previously sent your device a SET
* FEATURE setup packet which "armed" the
* remote wakeup capability.
*
* This callback should send a RESUME signal that
* has the period of 1-15ms.
*
* Note: Interrupt vs. Polling
* -Primary clock
* -Secondary clock ***** MAKE NOTES ABOUT THIS *******
* > Can switch to primary first by calling USBCBWakeFromSuspend()

* The modifiable section in this routine should be changed
* to meet the application needs. Current implementation
* temporary blocks other functions from executing for a
* period of 1-13 ms depending on the core frequency.
*


* According to USB 2.0 specification section 7.1.7.7,
* "The remote wakeup device must hold the resume signaling
* for at lest 1 ms but for no more than 15 ms."
* The idea here is to use a delay counter loop, using a
* common value that would work over a wide range of core
* frequencies.
* That value selected is 1800. See table below:
*
==========================================================
* Core Freq(MHz) MIP RESUME Signal Period (ms)
*
==========================================================
* 48 12 1.05
* 4 1 12.6
*
==========================================================
* * These timing could be incorrect when using code
* optimization or extended instruction mode,
* or when having other interrupts enabled.
* Make sure to verify using the MPLAB SIM's Stopwatch
* and verify the actual signal on an oscilloscope.
*******************************************************************/
void USBCBSendResume(void)
{
static WORD delay_count;

USBResumeControl = 1; // Start RESUME signaling

delay_count = 1800U; // Set RESUME line for 1-13 ms
do
{
delay_count--;
}while(delay_count);
USBResumeControl = 0;
}


/*******************************************************************
* Function: void USBCBEP0DataReceived(void)
*
* PreCondition: ENABLE_EP0_DATA_RECEIVED_CALLBACK must be
* defined already (in usb_config.h)
*
* Input: None
*
* Output: None
*
* Side Effects: None
*


* Overview: This function is called whenever a EP0 data
* packet is received. This gives the user (and
* thus the various class examples a way to get
* data that is received via the control endpoint.
* This function needs to be used in conjunction
* with the USBCBCheckOtherReq() function since
* the USBCBCheckOtherReq() function is the apps
* method for getting the initial control transfer
* before the data arrives.
*
* Note: None
*******************************************************************/
#if defined(ENABLE_EP0_DATA_RECEIVED_CALLBACK)
void USBCBEP0DataReceived(void)
{
}
#endif

/*******************************************************************
* Function: BOOL USER_USB_CALLBACK_EVENT_HANDLER(
* USB_EVENT event, void *pdata, WORD size)
*
* PreCondition: None
*
* Input: USB_EVENT event - the type of event
* void *pdata - pointer to the event data
* WORD size - size of the event data
*
* Output: None
*
* Side Effects: None
*
* Overview: This function is called from the USB stack to
* notify a user application that a USB event
* occured. This callback is in interrupt context
* when the USB_INTERRUPT option is selected.
*
* Note: None
*******************************************************************/
BOOL USER_USB_CALLBACK_EVENT_HANDLER(USB_EVENT event, void
*pdata, WORD size)
{
switch(event)
{
case EVENT_CONFIGURED:
USBCBInitEP();
break;
case EVENT_SET_DESCRIPTOR:
USBCBStdSetDscHandler();


break;
case EVENT_EP0_REQUEST:
USBCBCheckOtherReq();
break;
case EVENT_SOF:
USBCB_SOF_Handler();
break;
case EVENT_SUSPEND:
USBCBSuspend();
break;
case EVENT_RESUME:
USBCBWakeFromSuspend();
break;
case EVENT_BUS_ERROR:
USBCBErrorHandler();
break;
case EVENT_TRANSFER:
Nop();
break;
default:
break;
}
return TRUE;
}

/** EOF main.c *************************************************/