UNIVERSIDADE FEDERAL DE OURO PRETO
ESCOLA DE MINAS
COLEGIADO DO CURSO DE ENGENHARIA DE
CONTROLE E AUTOMAÇÃO - CECAU
PEDRO HENRIQUE SOUSA PRADO
CONTROLE E MONITORAMENTO DA TEMPERATURA DE UM AMBIENTE
UTILIZANDO UM CONJUNTO MICROCONTROLADOR/PC
MONOGRAFIA DE GRADUAÇÃO EM ENGENHARIA DE CONTROLE E
AUTOMAÇÃO
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 Automação
da Universidade Federal de Ouro Preto
como parte dos requisitos para a
obtenção do Grau de Engenheiro de
Controle e Automação.
Orientador: Henor Artur de Souza
Ouro Preto
Escola de Minas – UFOP
Dezembro/2011
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 (Graduação) – Universidade Federal de Ouro
Preto. Escola de Minas. Colegiado do Curso de Engenharia de Controle
e Automação.
Área de concentração: Engenharia de Controle e Automação.
1. Automação industrial. 2. Sistemas difusos. 3. Controle automático.
4. Conforto térmico. I. Universidade Federal de Ouro Preto. II. Título.
CDU: 681.5
Fonte de catalogação: [email protected]
SUMÁRIO
1INTRODUÇÃO
1.1Descrição do problema
1.2Objetivo
1.3Metodologia
1.4Estrutura do trabalho
2SISTEMAS DE CONTROLE
2.1Histórico dos sistemas de controle
2.2
Controle em malha fechada
2.3Controlador PID
2.3.1Ação Proporcional
2.3.2Ação Integral
2.3.3Ação Derivativa
2.4Controlador FUZZY PI
2.5Controle de sistemas de climatização
3MICROCONTROLADORES
3.1Arquiteturas dos microcontroladores
3.1.1Arquitetura CISC
3.1.2Arquitetura RISC
3.2Principais Componentes de um microcontrolador
3.2.1Memória
3.2.2Arithmetic Logic Unit (ALU)
3.2.3
Temporizadores e contadores
3.2.4
Interfaces de entrada e saída
3.2.5
Interrupções
3.3Microcontroladores PIC
3.3.1Microcontrolador PIC18F4550
3.3.1.1- Diagrama de pinos PIC18F4550
3.3.1.2- Diagrama de blocos PIC18F4550
3.3.1.3- Organização da Memória de Programa
3.3.1.4- Memória de Dados
3.3.2Comunicação USB/CDC em microcontroladores PIC
4ESTUDO DE CASO
4.1O objeto de estudo
4.2Proposta do sistema de controle
4.2.1Microcontrolador
4.2.2Sensor LM35
4.2.3Ventoinha
4.3Montagem do sistema de controle
4.4Desenvolvimento do software de controle
4.5Aplicação Web
4.6Resultados obtidos
5CONCLUSÕES
REFERÊNCIAS BIBLIOGRÁFICAS
ANEXO I (Código)
8
10
11
11
11
13
13
14
16
17
18
19
19
21
24
25
25
26
26
26
27
27
27
27
28
29
30
30
32
32
34
35
35
37
37
37
38
39
41
43
44
47
48
LISTA DE FIGURAS
Figura 2.1– Diagrama de blocos de um sistema de controle em malha fechada
14
Figura 2.2– Regiões das combinações possíveis entre as entradas
21
Figura 3.1– Desenho esquemático 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– Organização da Memória do PIC18F4550.
32
Figura 3.6– Memória de Dados do PIC18F4550.
33
Figura 4.1 – Visão frontal e lateral da maquete.
33
Figura 4.2 – Visão traseira e lateral da maquete
36
Figura 4.3– Visão 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 elétrico.
41
Figura 4.9–Diagrama USB/CDC
42
Figura 4.10– Tomcat Servidor
43
Figura 4.11– Tela principal.
44
Figura 4.12– Módulo NI USB-6009
45
Figura 4.13– Evolução temporal da temperatura interna do ambiente.
46
LISTA DE TABELAS
Tabela 2.1 – Efeitos no sistema das ações proporcional, integral e derivativa.
17
LISTA DE ABREVIATURAS
USB - Universal Serial Bus – Barramento universal serial
CDC - Communications device class - Comunicações classe de dispositivo.
HTML - HyperText Markup Language - Linguagem de marcação de Hipertexto.
HVAC - Heating, Ventilation and Air Conditioning – Aquecimento, Ventilação e
condicionamento de Ar.
CISC- Complex Instruction Set Computer. Conjunto de instruções complexas.
RISC – Reduced instruction Set Computer - Conjunto reduzido de instruções de
computador.
RAM – Random Access Memory - Memória de Acesso Aleatório.
EEPROM – Electrically Erasable Programmable Read-Only Memory - Memória
eletricamente apagável somente leitura programável.
ALU - Arithmetic Logic Unit - Unidade lógica e aritmética.
HID - Human interface device class - Classe de dispositivos de interface humana
P – Proportional – Proporcional
D – Derivative – Derivativo
I – Integral – Integral
LISTA DE SÍMBOLOS
e(t ) é o sinal de erro do processo;
k p é o ganho proporcional do controlador PID.
Ti é denominado tempo integral do controlador PID (s)
Td é o Tempo derivativo do controlador PID (s)
uPI nT  é a ação de controle no instante atual do controlador fuzzy PI.
uPI nT  T  é a ação de controle no instante passado do controlador fuzzy PI.
unT  incremento da ação de controle do controlador fuzzy PI.
K u é o ganho de saída do controlador fuzzy PI.
K i é uma constante de sintonia do controlador fuzzy PI.
K é uma constante de sintonia do controlador fuzzy PI.
r nT  T  é a variação do erro do controlador fuzzy PI.
enT  T  é o erro anterior do controlador fuzzy PI.
L é a faixa das variáveis de entrada do controlador fuzzy PI
RESUMO
O aumento da preocupação do homem com relação a seu bem estar e conforto é uma coisa
inerente à evolução da humanidade. Quanto mais evoluídas se tornam as pessoas mais
exigentes ficam com relação a seu conforto e bem estar. O uso de aparelhos que permitem o
condicionamento do ambiente é uma técnica comumente usada e difundida no cenário atual.
No entanto, o uso de aquecimento e/ou resfriamento artificiais de ar em edificações causam
um grande impacto do ponto de vista energético e ambiental. Tais aparelhos consomem
grande quantidade de energia e são responsáveis por 1/3 da energia consumida. No cenário
brasileiro, o uso do ar condicionado e a iluminação são responsáveis por 48 % do consumo
de energia elétrica no setor de edifícios comerciais e públicos. Diante disso, a busca por
sistemas de climatização que garantem um menor consumo de energia é uma área
tecnológica bastante promissora nos próximos anos. Nesse contexto a escolha das técnicas
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 climatização de
ambientes. O controle on-off é comumente utilizado nesse tipo de sistema, porém, tal
controle possui uma baixa robustez e um baixo rendimento energético. Neste trabalho
apresenta-se o controle fuzzy PI como uma técnica alternativa para o controle da
temperatura interna do ambiente construído e realiza-se um estudo sobre como implementar
os controladores nebulosos num sistema de climatização, visando obter as condições de
conforto dos usuários. O sistema de controle proposto tem como base um microcontrolador
PIC18F4550 e é aplicado em um modelo de edificação em escala reduzida. O
microcontrolador é capaz de comunicar-se via USB/CDC com um computador, o que
possibilita a visualização da dinâmica do sistema de controle em tempo real. O software de
aquisição e visualização de dados desenvolvidos é uma aplicação web e foi desenvolvido na
plataforma HTML/JavaScript. Por ser uma aplicação web, é possível a visualização do
sistema de controle de qualquer ponto na rede, visto que a maquina servidor opera como um
servidor local. Além de uma interface IHM muito amigável, o sistema de controle
desenvolvido neste trabalho apresentou desempenho adequado, mostrando-se robusto com
relação às perturbações impostas intencionalmente no ambiente.
Palavras-chave: controle fuzzy, controle inteligente, conforto térmico, comunicação
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- INTRODUÇÃO
O organismo humano se relaciona com o meio ao seu redor respondendo a estímulos
como luz, som, calor, ventos, entre outros, e busca se adaptar utilizando o mínimo de
energia possível, por meio de um conjunto de reações de ordem fisiológica e
psicológica. Estas reações são, em geral, respostas às condições ambientais que um
determinado espaço arquitetônico, em torno do individuo, pode propiciar.
No entanto, a sensação de conforto não depende apenas dos estímulos que o ambiente
construído, no qual o homem esta inserido, pode propiciar. Essa sensação de conforto é
influenciada também por fatores ligados a experiências pessoais anteriores de cada
individuo, onde este fator, por sua vez, garante que nem todas as pessoas em um mesmo
ambiente possuem mesmo de satisfação do conforto térmico (ASHRAE 55: 2004).
De modo geral, os estímulos do meio podem ser medidos com mais facilidade que as
sensações, pois estas correspondem ao sentimento e à avaliação subjetiva sobre o
ambiente. As condições de conforto e, conseqüentemente, a sensação de conforto,
envolvem um conjunto significativo de fenômenos inter-relacionados, que podem ser
agrupados em um conjunto representativo de exigências mínimas. Em linhas gerais,
estas exigências correspondem às características que um ambiente deve apresentar para
o desempenho adequado e confortável de diversas atividades humanas. Tais exigências
podem ser sintetizadas como a faixa de temperatura e umidade do ar relativas ao
conforto térmico; o conforto visual, que se relaciona com a iluminação do ambiente; o
conforto acústico, que esta relacionada com os níveis de ruídos e ao isolamento
acústicos; o conforto táctil, relativo às condições de eletricidade estática, rugosidade,
umidade e temperatura das superfícies; e também a qualidade do ar e a presença de
odores.
Embora sejam diversos os elementos que contribuem para a sensação de conforto,
caracterizada pela intensidade das respostas fisiológicas e psicológicas do individuo ao
meio que o cerca, a satisfação do ambiente térmico representa o fator predominante e
que modifica, além das reações de caráter subjetivo aos estímulos do meio ambiente
9
físico, outros fatores que contribuem para sensação de conforto, tais como idade, raça,
sexo, adaptabilidade ao meio, atividade física realizada (XAVIER, 1999, 2005).
O conforto térmico tem sido durante as últimas décadas objeto de muitas pesquisas, que
se tem por base a compreensão de como essa situação pode ser atingida, de que maneira
ela se processa, quais variáveis que a envolvem, quais são os índices mais relevantes,
quais seus efeitos sobre a saúde e produtividade humana e também quais fatores que a
ela podem ser relacionados (FANGER, 1972; SZOKOLAY, 1987, GIVONI, 1976, 1992).
A pesquisa em conforto ambiental nas edificações tem procurado tomar novas atitudes
frente à arquitetura e a automação predial. Em fase do pré-projeto da edificação é feita
uma análise sobre o material a ser utilizado, o clima do local e as variáveis construtivas
da planta da edificação. Quando se pretende alcançar as condições de conforto num
ambiente já construído, usam-se artifícios da automação predial acopladas às técnicas de
controle para condicionamento do ambiente. No entanto, apesar dos vários fatores que
influenciam o conforto dos usuários de uma edificação, as condições internas de
conforto de um ambiente são ditadas basicamente pelo valor da temperatura e umidade
relativa do ar.
As técnicas de controle aplicadas visam atender os pré-requisitos de projeto. Estes prérequisitos podem estar relacionados, por exemplo, à manutenção da temperatura e/ou
umidade do ambiente em torno de uma referência estabelecida pelo projetista, em
função das exigências dos usuários.
Ao se projetar um sistema de controle, é imprescindível em algumas ocasiões o
conhecimento do modelo matemático do processo. Porém, quando o sistema possui um
modelo bastante complexo ou é de natureza não linear, em alguns casos, essa
modelagem pode ser complicada. No entanto, é possível que um operador humano seja
capaz de controlar diversos sistemas sem compreender a matemática, ou todos os
detalhes físicos envolvidos.
Se opondo aos controladores convencionais, em que se descreve analiticamente o
algoritmo por equações diferenciais ou algébricas, no controle fuzzy utiliza-se regras
10
lógicas no algoritmo de controle, visando assim a incorporação da experiência humana
nas rotinas de controle. Os controladores fuzzy são bastante robustos e com grande
capacidade de incorporar conhecimentos de outros sitemas (ZADEH1, 1965, apud
SANDRI; CORREA, 1999). Estes controladores são considerados modelos versáteis
quanto se tem um modelo físico de alto grau de complexibilidade e difícil representação
matemática (SANDRI; CORREA, 1999).
1.1. Descrição do problema
Com o intuito de avaliar as interações térmicas do ambiente externo com o ambiente
interno de uma edificação, desenvolveu-se um protótipo de um modelo de edificação
em escala reduzida.
Propõem-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 não 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 comunicação USB/CDC, garantindo a
visualização das variáveis do sistema em tempo real. As variáveis são apresentadas em
uma aplicação web desenvolvida em JavaScrip.
A atuação no sistema é feita com o objetivo de manter a temperatura do sistema no
valor de referência. Se a temperatura é maior que a de referência 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 referência.
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 edificação em escala reduzida utilizando um microcontrolador PIC18F4550
interfaceado com um microcomputador via USB/CDC.
1.3. Metodologia
O desenvolvimento do trabalho engloba: (a) revisão sobre conforto térmico, lógica
Fuzzy, controle fuzzy PI, microcontroladores, desenvolvimento de softwares; (b)
montagem do modelo do ambiente em escala reduzida; e (c) proposição e
implementação do sistema de controle no ambiente.
A execução do trabalho foi baseada no seguinte roteiro de atividades:

Estudo de como desenvolver, na prática, 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
comunicação
do
microcontrolador
com
um
microcomputador.

Desenvolvimento de um Software para a aquisição de dados e monitoramento do
controle proposto;
1.4. Estrutura do trabalho
O presente trabalho encontra-se estruturado em cinco capítulos mais a lista de
referências bibliográficas e um anexo.
12
No capítulo 1 apresenta-se uma introdução, uma descrição do problema proposto e uma
apresentação dos objetivos e da metodologia adotada para o desenvolvimento do
trabalho.
No Capítulo 2 aborda-se uma discussão sobre sistemas de controle e são apresentados
fundamentos de diversas técnicas 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 equações do controlador fuzzy PI utilizado no presente trabalho.
No Capítulo 3 são abordados os fundamentos dos microcontroladores. É feita uma
descrição detalhada do microcontrolador PIC18F4550 pertencente à família PIC18
da MICROCHIP.
No Capítulo 4 apresenta-se o desenvolvimento prático do trabalho desenvolvido. É
apresentado os componentes eletrônicos utilizados na montagem bem como os
diagramas de ligação e resultados obtidos. Além disso, realiza-se uma abordagem
acerca da aplicação web desenvolvida em HTML/JavaScript.
No Capítulo 5 é feita uma abordagem conclusiva sobre o trabalho.
Finalmente são apresentadas as referências bibliográficas utilizadas, e um anexo
apresentando o código fonte do software desenvolvido para o microcontrolador no
software MPLAB IDE V8.60.
2- SISTEMAS DE CONTROLE
Embora muitas vezes não 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 função de monitorá-lo, está participando do
fechamento de uma malha. O primeiro dispositivo que utilizava controle em malha
fechada que se tem conhecimento é o relógio de água inventado por volta de 300 a.C.
Este relógio operava por meio do gotejamento de água, a uma taxa constante, dentro de
um reservatório medidor. O nível do reservatório medidor podia ser usado para informar
o tempo decorrido (HEY, 1997).
2.1- Histórico dos sistemas de controle
No decorrer dos anos vários trabalhos contribuíram para consolidação da teoria de
controle na atualidade. Segundo Ogata (2003) o primeiro trabalho significativo de
controle automático foi o regulador centrífugo construído por James Watt para o
controle de velocidade de uma máquina a vapor, no século XVIII.
Alguns termos importantes surgiram no decorrer do desenvolvimento do controle
automático, como, por exemplo, o próprio termo “automático” que implica no controle
efetuado sem a intervenção humana e o termo “realimentado” que foi utilizado pela
primeira vez nos Estados Unidos em 1920 quando do desenvolvimento de sistemas
telefônicos e amplificadores eletrônicos de realimentação por Bode, Nyquist e Black na
Bell Telephone Laboratories (DORF; BISHOP, 2005).
Durante a década de 1940, por exemplo, os métodos de resposta de freqüência tornaram
possível aos engenheiros projetar sistemas de controle em malha fechada satisfazendo
os requisitos de desempenho. Nesta mesma década, Walter R. Evans trabalhando na
indústria aeronáutica desenvolveu uma técnica gráfica para traçar as raízes de uma
equação característica de um sistema com retroação cujos parâmetros mudam de valor
sobre uma faixa particular de valores, tal método denominado lugar das raízes foi o
principal método para projetos de sistemas de controle neste período (OGATA, 2003).
14
Tendo em vista que os sistemas modernos, dotados de muitas entradas e muitas saídas,
se tornam cada vez mais complexos, a descrição de um sistema de controle envolve um
grande número de equações. A teoria de controle clássica, que trata somente de sistemas
com uma única entrada e uma única saída, tornou-se insuficiente para lidar com
sistemas de entradas e saídas múltiplas. A partir de 1960, a disponibilidade dos
computadores digitais tornou possível a análise, no domínio do tempo, de sistemas
complexos, ensejando o desenvolvimento da moderna teoria de controle baseada nas
técnicas de análise e síntese por meio de variáveis de estado. Esta teoria foi
desenvolvida com o objetivo de tratar a complexidade crescente dos sistemas modernos
e atender às rigorosas exigências quanto ao peso, exatidão e custos de projetos relativos
às aplicações militares, espaciais e industriais.
Durante o período de 1960 a 1980, foram investigados os controles ótimos de sistemas
determinísticos e estocásticos bem como o controle adaptativo e o controle com
aprendizado. De 1980 aos dias de hoje, os desenvolvimentos na moderna teoria de
controle têm se concentrado no controle robusto.
2.2- Controle em malha fechada
O controle de sistemas em malha fechada utiliza um sinal de medição atual da saída do
sistema para comparar com um sinal de referência previamente estabelecido. O sinal de
saída medido é chamado de sinal de realimentação ou feedback. Na figura 2.1 mostra-se
o diagrama de blocos e o fluxo de informações 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 saída da planta e E(S ) o sinal de erro
atuante (diferença entre R(S) e Y(S)). Em geral, indica-se a função de transferência
(modelo matemático) de malha fechada por T(S ), a função de transferência no caminho
da alimentação direta e representada por G(S ) e a função de transferência no caminho
da realimentação por H(S ). Tem-se, portanto, que a função de transferência em malha
fechada para o diagrama apresentado é
T ( s) 
Y ( s)
Gc( s)Gp( s)

R( s) 1  Gc( s)G( s) H ( s)
(2.1)
O elemento de medição (sensor) é a parte do sistema responsável por realizar a medição
de alguma propriedade do sistema, bem como a sua conversão em alguma variável
física que possa ser interpretada pelo sistema de controle. Em alguns casos, isto não
ocorre e torna-se necessário a utilização de elementos transdutores e transmissores para
converter e adequar o sinal ao sistema de controle. Ocorre em muitos casos também de
o próprio elemento sensor ser o elemento transdutor do sinal. O sinal obtido pelo
elemento de medição é, então, enviado ao controlador, que é a parte mais importante do
sistema de controle. O controlador funciona como o cérebro do sistema, tomando
decisões baseadas em informações disponíveis e repassando-as ao elemento final de
ação (atuador). O atuador é o elemento do sistema de controle responsável por exercer a
ação sobre o processo de modo a colocá-lo dentro dos padrões desejados.
Um sistema de controle em malha fechada utiliza-se de uma função que relaciona o
sinal de saída com o sinal de entrada. Geralmente a diferença entre o sinal de saída 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 diferença entre estes sinais seja
reduzida. O controle de um sistema por meio de uma malha fechada oferece inúmeras
vantagens. O uso da realimentação faz com que a resposta do sistema seja relativamente
insensível a distúrbios e variações internas dos parâmetros 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 número 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. Além disso, os sensores podem introduzir ruídos e
imprecisões no sistema.
O controle em malha fechada é utilizado para fornecer o máximo de desempenho e
robustez ao sistema. Qualitativamente, o desempenho de um sistema de controle pode
ser avaliado pela sua capacidade em manter a variável controlada próximo a um valor
desejado, mesmo em presença de perturbações externas. A robustez deve proporcionar
ao sistema de controle um bom desempenho tanto para pequenas quanto para grandes
perturbações.
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 são controlados
pelo PID ou por esse algoritmo com pequenas variações. Esse tipo de controlador tem
sua saída da seguinte forma
1

1
de(t ) 

u (t )  k p  e(t )   e( )d  Td

T
dt
i 0


(2.2)
onde u (t ) é o sinal de controle; k p é o ganho proporcional do controlador; e(t ) é o sinal
de erro do processo; Ti é denominado tempo integral do controlador e Td é o Tempo
derivativo do controlador.
O ajuste de um controlador PID, que é denominado sintonia do controlador, é feito
variando os valores de k p , Ti e Td . Na tabela 3.1 apresenta-se um resumo da influência
das ações proporcional, integral e derivativa no controlador PID.
17
Tabela 2.1 – Efeitos no sistema das ações proporcional, integral e derivativa.
Ação
Proporcional
Tempo de
Subida
Diminuição
Integral
Derivativo
Sobreelevação
Aumento
Tempo de
Estabelecimento
Sem Alteração
Erro Estacionário
Diminuição
Diminuição
Aumento
Aumento
Elimina
Sem alteração
Diminuição
Diminuição
Sem Alteração
Fonte: LOURENÇO, 1997.
O processo de selecionar parâmetros do controlador que garantam uma dada
especificação 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 ação proporcional é utilizada. As regras sugerem um
conjunto de valores k p , Ti , Td . que vão proporcionar uma operação estável ao sistema.
Contudo, o sistema resultante pode exibir um máximo sobre-sinal grande devido à
resposta ao degrau, o que e inaceitável. Nesse caso, e necessário fazer uma série de
sintonias finas até que um resultado aceitável seja obtido. De fato, as regras de ZieglerNichols2 (1942, apud OGATA, 2003) fornecem estimativas dos valores dos parâmetros
e proporcionam um ponto de partida na sintonia fina, e não os valores definitivos de k p ,
Ti , Td logo na primeira tentativa (OGATA, 2003).
Ziegler e Nichols2 (1942, apud OGATA, 2003) propuseram dois métodos para a
sintonia de controladores PID. O primeiro método é baseado em um processo de malha
aberta, ao passo que o segundo método é baseado no ganho crítico da malha fechada.
2.3.1- Ação Proporcional
No controle puramente proporcional a ação de controle é proporcional ao sinal de erro
atuante e sua equação é descrita da seguinte forma:
2
Ziegler, J. G. And N. B. Nichols (1942). “Optimum Settings for Automatic Controllers,”
Trans. ASME, 64, 759-768.
18
g C (t )  K p E (t )
(2.3)
onde g C (t ) é a saída do controlador; K p é o ganho proporcional e E(t) é o erro atuante
no processo.
Para que o sinal de erro atuante seja nulo, é necessário que o valor da variável
manipulada seja igual ao valor de referência (setpoint). Quando a condição desejada, ou
seja, valor da variável 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 condição desejada. Muitos
controladores que operam apenas no modo proporcional adicionam um valor constante
à variável manipulada para garantir que na condição desejada alguma energia seja
entregue ao sistema. Este valor é denominado bias (polarização) e quando ajustável
permite que se obtenha uma estabilização próxima da condição desejada. Este tipo de
controle é uma forma simples de controle realimentado (ASTROM; HAGGLUND,
1988).
2.3.2- Ação Integral
A ação integral atua de sistema gerando uma resposta na saída do controlador que é
proporcional a amplitude e duração do sinal de erro atuante. A ação integral tem o efeito
de eliminar o erro característico de um controle puramente proporcional. A ação integral
funciona da seguinte maneira: em intervalos regulares, a ação integral corrige o valor da
variável manipulada, somando a esta o valor do erro atuante. Este intervalo de tempo é
o tempo integral (Ti). Na equação (2.4) descreve-se matematicamente uma ação de
controle integral.

g c (t )  K p E (t )  ki  E (t )dt

(2.4)
A ação integral adiciona um pólo na origem da função de transferência do controlador,
eliminando assim o erro estacionário de posição, independentemente do sistema que se
19
pretende controlar. Se, por um lado, como já referimos anteriormente, a ação integral
elimina o erro estacionário, por outro, ela aumenta o tempo de estabelecimento e piora a
estabilidade relativa, o que usualmente é indesejável (LOURENÇO, 1997).
2.3.3- Ação derivativa
A função da ação derivativa é melhorar a estabilidade em malha fechada do sistema.
Assim como o controle integral, o controle derivativo não é, isoladamente, uma técnica
de controle, pois não é empregado sem o acompanhamento de uma ação de controle
proporcional. A ação de controle derivativa consiste em uma resposta na saída do
controlador que é proporcional a velocidade de variação do erro atuante, conforme se
descreve na equação (2.5).
dE (t ) 

g C (t )  k p  E (t )  K d
dt 

(2.5)
A ação derivativa tem o efeito de reduzir a velocidade das variações do valor da
variável controlada, evitando que ela se eleve ou reduza muito rapidamente.
O termo derivativo só atua quando há variação no erro. Se o processo esta estável, seu
efeito é nulo. Durante perturbações ou na partida do processo, quando o erro está
variando, o derivativo sempre atua no sentido de atenuar as variações, sendo, portanto, a
sua principal função melhorar o desempenho do processo em regime transitório.
Embora o controle derivativo não afete diretamente o erro estacionário, ele aumenta o
amortecimento do sistema, permitindo, assim, a utilização de um valor mais levado do
ganho K , o que vai resultar em maior precisão 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 saída do
controlador. A relação entre entradas e saídas no controlador fuzzy é obtida por meio de
20
conhecimentos especialistas do sistema, ou seja, técnicas de inteligência artificial.
Geralmente a lei de controle é apresentada como uma fórmula matemática discreta,
possibilitando assim o uso do controle em qualquer dispositivo digital que tenha
capacidade
de
realizar
cálculos
(Controladores
lógicos
programáveis,
DSP,
microcontroladores).
Existem varias etapas para se obter as equações de um controlador fuzzy PI. Dentre
essas etapas estão a fuzzificação das entradas, a base de regras do controlador e a
defuzzificação. A dedução da lei de controle do controlador fuzzy PI é apresentada em
Oliveira (2008) e tem como base as seguintes equações.
uPI nT   uPI nT  T   Ku  uPI nT 
(2.6)
u nT  
LK i  enT  T   K  r nT 
22 L  K i  enT  T  
Nas regiões IC1, IC2, IC5 e IC6
(2.7)
u nT  
LK i  enT  T   K  r nT 
22 L  K  r nT  
Nas regiões IC3, IC4, IC7 e IC8
(2.8)
u nT  
1
K  r nT   L
2
Nas regiões IC9 e IC10
(2.9)
u nT  
1
K i  enT  T   L
2
Nas regiões IC11 e IC12
(2.10)
u nT  
1
K  r nT   L
2
Nas regiões IC13 e IC14
(211)
u nT  
1
K i  enT  T   L
2
Nas regiões IC15 e IC16
(2.12)
unT   0
Nas regiões IC18 e IC20
(2.13)
unT   L
Nas regiões IC17
(2.14)
unT    L
Nas regiões IC19
(2.15)
onde uPI nT  é a ação de controle no instante atual; uPI nT  T  é a ação de controle no
instante passado; K u ganho de saída do controlador fuzzy; unT  é o incremento da
ação de controle;
Ki K
e são constantes de sintonia do controlador PI; enT  T  é o
21
erro do controlador(Variável de entrada); r nT  T  é a variação do erro anterior do
controlador (Variável de entrada); L é a faixa das variáveis de entrada do controlador.
Os valores de entradas definem as regiões do controlador que esta trabalhando. Na
figura 2.2 exemplifica-se a definição das regiões citadas nas equações (2.7) a (2.15).
Figura 2.2 – Regiões das combinações possíveis entre as entradas
Fonte: Adaptada de TANG; CHEN; LU, 2001
2.5- Controle de Sistemas de Climatização
Existem vários tipos de abordagens para tratar o problema de conforto térmico em
edificações climatizadas artificialmente. Tais soluções visam promover melhores
condições de conforto térmico no interior de ambiente.
Em controle de ambientes, a abordagem mais difundida é a que faz o tratamento das
condições climáticas no interior do ambiente tomando-se como parâmetros de controle a
otimização tanto da temperatura como da umidade relativa do ar. O controle em malha
22
fechada típico nesse tipo de abordagem abordagem é realizado com a realimentação do
sinal de temperatura e umidade relativa, que é mensurado através de sensores no
ambiente no qual se efetua a climatização artificial. Nas ultimas décadas vários
trabalhos foram desenvolvidos nessa perspectiva. Na seqüência apresenta-se alguns
trabalhos relacionados com essa abordagem onde procura-se compreender os pontos
positivos e negativos em variar as duas principais variáveis que afetam as condições
higrotérmicas no interior de uma edificação.
Astrom,; Hagglund e Wallenborg (1993) apresentam uma tentativa de otimização
melhorando o desempenho de controladores digitais em sistemas HVAC(heating,
ventilation, and air conditioning) por meio de um mecanismo de auto-ajuste. Utilizandose de estruturas de controle digitais, evitando-se assim problemas de discretização de
estruturas contínuas para tratamento das variáveis consideradas no sistema, apresenta-se
uma melhora no desempenho para sistemas de baixa ordem, atuando-se na temperatura
interna do ambiente e na pressão dos dutos de ventilação do sistema.
Já Dumur; Boucher e Murphy (1997) propõem uma estratégia que antecipa futuras
mudanças no set-point de temperatura para manter o sinal o mais próximo possível do
valor ideal. Tal estratégia, 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 sensação
de conforto térmico, pode ser suficiente ajustar uma faixa de temperatura em virtude de
se obter um controle regularizado em um valor pré-estipulado. Tal característica é então
explorada por uma lei de controle baseada em sistemas fuzzy.
Pode-se citar ainda, como estratégia de controle para temperatura e umidade relativa, o
trabalho proposto por Rentel-Gomez e Velez-Reyes (2001) onde, desprezando-se a
hipótese de alto consumo de energia, utiliza-se de uma técnica de controle multivariável
de temperatura e umidade relativa em cascata para manter seus respectivos valores o
mais próximos possível dos set-points pré-determinados. A estratégia de controle
proposta possui dois laços na malha de controle, o laço interno utiliza-se de uma lei de
23
controle não-iterativa para desacoplar as duas variáveis de saída (temperatura e umidade
relativa internas do ambiente) em relação as entradas (variáveis do sistema de
climatização e perturbações), já o laço externo, voltado a estabilização e controle
propriamente dito, utiliza-se de um controlador do tipo proporcional e derivativo (PD).
Apresentam-se ainda resultados onde atuam-se em cada variável separadamente,
considerando-se nulas as infiltrações entre o ambiente e o clima externo.
No trabalho em questão, utiliza-se uma malha de controle baseado no controle
regulatório da temperatura interna do modelo de edificação em escala reduzida. Esse
controle tem por objetivo manter a variável de processo (temperatura) em valores
desejados (setpoints), ou oscilando em faixas pré-definidas. A atuação do controlador é
feita com a insuflação de ar frio na instalação a partir de uma ventoinha.
3- MICROCONTROLADORES
O microcontrolador pode ser definido como um circuito integrado composto por um
microprocessador e dispositivos periféricos. Pode-se dizer que existe dispositivos
periféricos essenciais, tais como: memória de programa e de dados; e também
periféricos de acessórios como: interfaces de entrada e saída de dados. Encontra-se em
um microcontrolador vários dispositivos eletrônicos como conversor analógico digital
(AD), comparadores, interfaces de comunicação como USB/SERIAL, geradores de
pulsos, temporizadores, entre outros. São muito populares devido ao seu baixo custo.
Isso possibilita a utilização de microcontroladores como soluções de vários projetos que
tem como prioridade o baixo consumo de energia e baixo custo.
Os microcontroladores possuem freqüência de clock de poucos MHz e são considerados
lentos comparados aos microprocessadores utilizados em computadores convencionais,
no entanto ele são bastante adequados para aplicações típicas. Além disso esses
dispositivos consomem pouca energia, variando na faixa de miliwatts de potencia
consumida (HORENSTEIN, 2006).
Outra grande vantagem dos microcontroladores é a fácil programação e reprogramação,
o que o torna uma ferramenta importante em vários sistemas embarcados como
celulares, eletrodomésticos, equipamentos de automação industrial, relógios, alarmes,
brinquedos e outros, pois podem ser desenvolvidos para aplicações especificas.
Atualmente,
grande
parte
dos
componentes
eletrônicos
utilizados
possuem
microcontroladores em sua arquitetura. Os microcontroladores possuem uma
capacidade de processamento que depende da família de processadores que os mesmos
utilizam. Apresenta-se a organização de um microcontrolador padrão na figura 3.1.
25
Figura 3.1- Desenho esquemático de um microcontrolador.
Fonte PICMINAS, 2011.
3.1- Arquiteturas dos microcontroladores
A organização interna dos microcontroladores pode se dar de várias formas diferentes, e
isso impactará diretamente em sua capacidade de armazenamento, consumo de energia,
programação e desempenho. Os fabricantes de microcontroladores implementam a
arquitetura organizacional dos microcontroladores seguindo paradigmas e conceitos
consolidados pela computação. As arquiteturas mais utilizadas são 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 utilização de instruções mais complexas,
objetivando assim a diminuição do numero de instruções que o programa necessita para
ser implementado. Nesses dispositivos o numero de ciclos por instruções pode aumentar
26
assim como o próprio tempo de relógio. Pode-se citar como exemplo de utilização da
arquitetura CISC os processadores da família de microcontroladores Intel 8051, que
possuem cerca de 100 instruções.
3.1.2- Arquitetura RISC
A arquitetura RISC tem como base a utilização de instruções de baixa complexidade, o
que gera um baixo tempo médio de execução das instruções de maquina. Essa redução
de tempo, por sua vez, gera um menor numero de ciclos por instruções, no entanto, o
numero de instruções utilizadas no programa aumenta consideravelmente em relação a
arquitetura CISC. Pode-se citar como exemplo de utilização da arquitetura RISC os
microcontroladores da família PIC. A exemplo disso tem-se o PIC da família 16F que
possui um pouco mais de 30 instruções.
Pode-se dizer que os dispositivos que utilizam a arquitetura RISC tem como objetivo a
redução máxima do tempo de ciclo de via de dados.
3.2- Principais Componentes de um microcontrolador
Um microcontrolador pode ser subdividido em vários componentes. A seguir descrevese as principais partes dos sistemas microcontrolados.
3.2.1 Memória
Um dos componentes principais de um microcontrolador é a memória. A memória de
sistemas microprocessados pode ser dividida em dois grupos, sendo eles: memória de
programa (FLASH) e memória de dados
(RAM – Random Access Memory e
EEPROM - Electrically-Erasable Programmable Read-Only Memory). A utilização da
memória de programa está relacionada com o armazenamento de tarefas que o
microcontrolador deve executar. Já a memória de dados é utilizada para armazenar os
resultados e dados utilizados pelo microcontrolador. Apesar das diferenças, ambas
memórias 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) é responsável pelas
operações lógicas realizadas nesse dispositivo. A ALU é considerada a central de
processamento do dispositivo e tipicamente realiza operações lógicas de comparação
como maior, menor, igual; operações booleanas como and, or, xor; operações
aritméticas como adição, subtração, incrementação, multiplicação e divisão.
3.2.3 Temporizadores e contadores
A noção de tempo e execução de rotinas nos sistemas microcontrolados é realizadas
pelos temporizadores e contadores. Podem gerar pulsos, rotinas em períodos
específicos, entre outros. Seus parâmetros são alteráveis, tornando o seu uso
programável para uso especifico ou geral.
3.2.4 Interfaces de entrada e saída
Os microcontroladores se interfaceam com outros dispositivos através de portas de
entradas e saídas. Essa transmissão de dados com o meio externo pode ser via
comunicação serial, paralela e USB. Uma comunicação bastante utilizada em
microcontroladores é a comunicação USB/CDC no qual a comunicação do tipo serial é
emulada na porta USB.
3.2.5- Interrupções
O programa principal pode ser interrompido pelas chamadas rotinas de interrupção.
Pode-se dizer que as interrupções são modificações que ocorrem no fluxo de controle
causada por uma ação externa. A interrupção opera como um sinal de controle enviado
para à CPU, quando se detecta um determinado evento. Após isso, a CPU é forçada a
tratar o evento externo. É possível dividir o tratamento de interrupções em três etapas,
que são descritas a seguir:
28
 detecção da fonte da interrupção, ou seja, qual dispositivo que gerou a ação
externa;

executar as ações relacionadas com o tipo de interrupção gerado;
 retornar ao ponto do programa em que estava quando iniciou atendimento à
interrupção;
Quanto um ou mais dispositivos enviam o sinal de interrupção ao mesmo tempo as
interrupções são atendidas de acordo com o grau de prioridade. São prioritárias para
atendimento as interrupções devidas a:
 emergências de hardware, tais como atendimento a reset(reinicicalização) e erros
de hardware (erro de paridade de memória,etc.);
 eventos de alta prioridade;
 E/S de dispositivos de alta velocidade.
3.3- Microcontroladores PIC
Os microcontroladores PIC são uma família de dispositivos fabricados pela Microchip.
Esses dispositivos utilizam uma arquitetura RISC e possuem freqüências de clock de até
40MHz. Além disso, eles podem ter até 2048 Kword de memória de programa e até
3968 bytes de memória RAM. Podem ser encontrados com diversos periféricos
internos, tais como: temporizadores/contadores, memória EEPROM interna, gerador,
comparador, amostrador PWM, conversores A/D de até 12 bits, interface de barramento
CAN, I2C,SPI, entre outros.
Existem basicamente três famílias de PICs sendo elas diferenciadas pelo tamanho da
palavra de memória de programa: 12,14 e 16 Bits. Todos estes dispositivos possuem um
barramento interno de dados de oito bits. Outra característica importante da arquitetura
PIC reside na semelhança e compatibilidade entre os diversos chips. Isto facilita
grandemente a migração de um MCU para outro, pois os princípios básicos e grande
parte dos registradores não diferem entre si (HORENSTEIN, 2006).
29
3.3.1 - Microcontrolador PIC18F4550
O microprocessador PIC18f4550 (figura 3.2) reúne, 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 características
desse dispositivo (DATASHEET, 2006).

Frequencia de Operação: 48 MHz; - Memória de Programa (instruções): 16384;

Memória 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;

Comunicação Serial – Enhanced UART: 2;

Comunicação Serial – SPI (3-wire/4-wire): 3;

Comunicação Serial – I2C: 2;

Comunicação Paralela (PMP/PSP): Não;

Streaming Parallel Port (SPP) for USB streaming transfers: Sim;

Packages: PLCC, TQFP, DIP ou SOIC;

Set (Instruções): 75/ 83 com Set de Instruções 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 contém uma função executada pelo microcontrolador PIC18F4550, figura 3.4:
31
Figura 3.4: Diagrama em Blocos do PIC18F4550.
Fonte: DATASHEET..., 2006.
32
3.3.1.3- Organização da Memória de Programa
A memória de programa deste componente se comporta conforme o esquema
apresentado na figura 3.5.
Figura 3.5: Organização da Memória do PIC18F4550.
Fonte: DATASHEET..., 2006.
3.3.1.4- Memória de Dados.
A memória de dados é onde o microcontrolador lê e escreve dados durante a operação
normal. Geralmente é do tipo volátil, embora memórias não-voláteis possam ser
33
utilizadas (DATASHEET..., 2006). Observe-se no diagrama mostrado na figura 3.6 a
estrutura de memória de dados do PIC18F4550.
Figura 3.6- Memória de Dados do PIC18F4550.
Fonte: DATASHEET...,2006.
34
3.3.2- Comunicação USB/CDC em microcontroladores PIC
A especificação USB (USB-IF) define classes de comunicação para os mais variados
tipos de comunicação (interrupção, transferência em massa, etc. Dentre essas classes de
comunicação que o padrão USB define, duas classes foram consideradas para
desenvolver dois tipos de comunicação USB: CDC e HID.
A classe de comunicação CDC (Connected Device Configuration),desenvolvida nesse
projeto, se enquadra em uma série de classes que definem transferências genéricas de
dados, como transferência de sinais de controle e dados em modems, cabos Ethernet e,
para o caso deste trabalho,transferências que emulam a transmissão de dados através da
comunicação serial RS232 (AXELSON, 1996).
A especificação CDC descreve a subclasse Abstract Control Model(IARSYSTEMS)
para a emulação serial através do USB. Basicamente, para que a emulação RS232 possa
ser realizada duas interfaces (classes) USB são necessárias: Communication Interface
Classe Data Interface Class. A primeira interface encarrega-se de notificar ao servidor –
neste caso uma estação de controle, um computador pessoal – do status da conexão
USB-RS232 oriunda do dispositivo.A segunda interface define a forma como os dados
serão enviados já que, no padrão RS 232, os dados são mandados em sua forma crua
(raw data), sem qualquer formatação (AXELSON, 1996).
4. ESTUDO DE CASO
4.1. O objeto de estudo
Este trabalho tem como principal objetivo o estudo, implementação, e análise de um
sistema de controle fuzzy PI de temperatura num modelo de edificação em escala
reduzida (OLIVEIRA,2008). Além disso, é realizada um interfaceamento do
microcontrolador com um computador, possibilitando, por parte do usuário, a
visualização e o interfaceamento em tempo real com o sistema de controle.
O modelo de edificação em escala reduzida é uma casa de madeira em dimensões
reduzidas. Apresenta-se o modelo nas figuras 4.1, 4.2, 4.3. A maquete possui as
dimensões de 62,5 cm de largura, um comprimento de 62 cm e uma altura de 37 cm.
Figura 4.1 – Visão frontal e lateral da maquete
36
Figura 4.2 – Visão traseira e lateral da maquete
Figura 4.3– Visão 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 variável 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 responsável pela aplicação 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 é responsável por calcular a tensão média a ser entregue ao
atuador a partir do algoritmo de controle fuzzy, ou seja, ele fornece a potência
necessária a ventoinha, de maneira que este insufle uma quantidade de ar necessária
para a manutenção da temperatura interna do ambiente em um valor de referência préestabelecido.
4.2.2. Sensor LM35
O LM35 é um sensor de temperatura de precisão fabricado pela National
Semiconductor, figura 4.4. Este dispositivo possui uma tensão de saída diretamente
proporcional à temperatura na escala Celsius, sendo de 10 mV/ºC. O LM35 não
nescessita de qualquer calibração e possui uma boa exatidão, valores de temperatura
com variações 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 saída de tensão direta, é muito fácil realizar-se o seu
interfaceamento com dispositivos de leitura analógicos. No presente estudo, o sinal de
tensão do sensor é amplificado por um amplificador operacional e posteriormente
enviado para a porta analógica do microcontrolador.
38
Figura 4.4 – Sensor LM35
Este sensor permite uma alimentação VS variando na faixa de 4 a 20 Vdc e drena apenas
60 µA de sua fonte de alimentação, o que gera um baixo aquecimento por efeito joule.
O sensor LM35 pode ser encontrado em vários tipos de encapsulamentos, cujo a escolha
depende do tipo de aplicação 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
características de um motor de corrente continua e tem a função de insuflar uma
quantidade de ar frio no ambiente interno, de tal modo que se mantenha a temperatura
constante em um valor de referência.
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 potência desenvolvida no dispositivo é controlada
pelo microcontrolador por meio de uma modulação 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 máxima, e consequentemente em sua
tensão máxima, 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 eletrônico de medição
de temperatura, situado no ambiente externo. Este circuito é composto por um
amplificador operacional e duas resistências. A ventoinha se encontra acoplada em uma
das janelas do modelo de edificação 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 elétrico do sistema de controle. Observa-se neste
esquema elétrico que a saída do sensor de temperatura é amplificada pelo dispositivo
LM741. Essa amplificação é ditada pelas resistências 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 precisão da medição, logo,
41
a utilização do LM741 para amplificar a temperatura nos fornece um grande aumento da
precisão do sistema.
Figura 4.8 – Diagrama elétrico.
Utiliza-se um diodo em paralelo com a ventoinha, denominado diodo de roda livre. Este
dispositivo tem a função de proteger o circuito eletrônico, o transistor em particular, de
uma descarga reversa da força contra-eletromotriz gerada na ventoinha. Com o diodo de
roda livre esta descarga elétrica da força contra eletromotriz circulará em torno do diodo
e não mais no transistor.
Utiliza-se os botões RESET e MUDA SETPOINT, que são responsáveis por reiniciar o
sistema e alterar o valor de referencia do controle regulatório, respectivamente.
Os dados do processo podem ser vistos em dois dispositivos. O primeiro deles é o leitor
LCD. No display LCD é possível a leitura da temperatura interna do ambiente, do ciclo
de trabalho do cooler e da temperatura de referência (setpoint). Já a segunda forma de
leitura se baseia no interfaceamento do sistema com o microcomputador, que permite a
visualização 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
série de funcionalidades, como geração do código fonte, compilação e teste do chip
42
escolhido pelo projetista, em um ambiente amigável e de fácil compreensão. Utilizou-se
a linguagem C. Sendo assim, necessita-se de um compilador para converter essa
linguagem de alto nível para a linguagem de máquina do microcontrolador.
A escrita do código se subdivide em três partes. A primeira delas é o programa
destinado a aquisição de sinais externos, valores de temperatura, por exemplo, e envio
de sinais para dispositivos externos. Nessa etapa, utiliza-se bibliotecas para conversão
analógica/digital, acesso as saídas PWM e interface com o display LCD.
Posteriormente, desenvolveu-se uma parte do código dedicado ao sistema de controle.
Nessa parte, é possível calcular o ciclo de trabalho a ser aplicado na ventoinha a partir
de cálculos da lei de controle fuzzy PI.
A última parte do software é destinada a comunicação USB/CDC, figura 4.9. É
realizado o empacotamento dos dados e através de uma interface com componentes
eletrônicos, é possível 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 emulação da porta serial.
Figura 4.9 – Diagrama USB/CDC.
Analisando o sistema com uma visão 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 comparação, gera-se o sinal de erro do
sistema, que representa a diferença do estado atual para o estado de referência. Em
seguida, a partir da lei de controle do controlador fuzzy PI, calcula o incremento
necessário na saída do controlador para controlar a temperatura interna do ambiente.
Esse incremento é adicionado a saída atual, e a saída do controlador é atualizada,
43
fazendo com que a potência da ventoinha diminua de acordo com o incremento. Após a
compilação do software de controle, este deverá ser gravado no microcontrolador.
4.5. Aplicação Web
Por meio da conexão USB/CDC os dados são 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 aplicação web
realizada com o Java Script. A aplicação 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 aplicação 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 aplicação 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 equações discreta do controlador, é
possível concluir que a sintonia deste sistema depende apenas das constantes K , K i e
K u e dos parâmetros T (tempo de amostragem) e  L, L (faixa das variáveis de
entrada do controlador).
A dinâmica de sistemas térmicos é caracterizada por uma resposta lenta, com isso
utiliza-se o tempo de amostragem de 1 s. Já o parâmetro L é definido com o valor fixo
igual a 1. Com isso tem-se, T  L  1 .
Após vários experimentos realizados no processo, conclui-se que os melhores valores
dos ganhos do controlador são:
K  10
Ki  1
K u  40
45
O sistema desenvolvido permite ao usuário a visualização em tempo real do sistema de
controle, no entanto, para se gerar o gráfico da evolução temporal da temperatura,
utiliza-se o módulo NI USB-6009 para aquisição de dados, figura 4.12. Utiliza-se o
Software Labview para o armazenamento dos dados no computador.
Figura 4.12 – Módulo NI USB-6009
Apresenta-se na figura 4.13 a evolução da temperatura interna do ambiente sob a
atuação 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 referência e o sistema de controle
é ligado. A temperatura do ambiente se estabiliza no valor de referência 3 min após o
sistema de controle iniciar sua operação.
46
Figura 4.13 - Evolução temporal da temperatura interna do ambiente.
47
5. CONCLUSÕES
Neste trabalho desenvolve-se em um microcontrolador da família 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 possível obter
as leis de controle discretas do controlador fuzzy PI, possibilitando assim uma
implementação pratica.
O microcontrolador utilizado é capaz de fazer a leitura do sensor de temperatura e
calcular a potência a ser entregue ao atuador para que se controle a temperatura do
ambiente. Além disso, o microcontrolador se comunica com um computador doméstico
por uma conexão USB/CDC, possibilitando assim a visualização em tempo real do
sistema de controle.
O sistema de controle proposto no trabalho apresentou um desempenho satisfatório,
visto que o mesmo conseguiu conduzir
à temperatura de referência em
aproximadamente 3 min.
A IHM (Interface Homem Maquina) para visualização dos dados no computador é uma
aplicação WEB e foi desenvolvida na plataforma HTML/JavaScript. Essa aplicação
possibilita a visualização em tempo real do sistema de controle de qualquer ponto ligado
a rede.
Além disso, em virtude dessa aplicação 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 aplicações Java.
Como sugestões para trabalhos futuros propõem-se a utilização de um sistema que
permita não só resfriar o ambiente construído, mas também aquecê-lo. Além disso, a
aplicação 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 serviço de internet.
48
REFERÊNCIAS BIBLIOGRÁFICAS
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º Edição.
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
PC’s
parallel
printer
port.
1996.
Disponível
em:
<http://www.lvr.com/parprtib.htm#Chapter1>. Acesso em: 25 de novembro de 2011.
DATASHEET do microcontrolador
PIC18F4550
disponível 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º Edição. 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 Didático de Sistemas de Controle I. 1º ed.
Santa Maria, 1997.
HORENSTEIN, M. N., Microeletrônica circuitos & dispositivos, Rio de Janeiro.
Editora Prentice-Hall do Brasil, 1996
LOURENÇO, J. Sintonia de Controladores PID. Rio de Janeiro: 1997.
OGATA, K. Engenharia de Controle Moderno. 4º Edição. São Paulo: Prentice Hall,
2003.
OLIVEIRA, I. S. Controle fuzzy PI de temperatura num modelo de edificação em
escala reduzida. 2008. Monografia (Trabalho de Final de Curso em Engenharia de
Controle e Automação). Escola de Minas, Universidade Federal de Ouro Preto, Minas
Gerais, 2008.
OLIVEIRA, G. H. C.; ARAÚJO, 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. Lógica Nebulosa. In: ESCOLA DE REDES NEURAIS, 5.,
1999, São José dos Campos. Anais... São José dos Campos: ITA, 1999, p. c73-c90.
SIMPSON,
B.
Tomcat
Howto,
1ª
ed.
2007
Disponível
<http://pub.admc.com/howtos/tomcat/tomcat.pdf>. Acesso em: 13 de dez. 2011.
em:
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. 109119, 2001.
TORRES, F. E.; MARTINS, H. R. Apostila didática PICMinas: Sistemas
microcontrolados, V. 1. Editora Axoon, 2010.
XAVIER, A. A. P. Condições de conforto térmico para estudantes de 2º grau na
região de Florianópolis. Florianópolis. 1999. 198 p. Dissertação (Mestrado) Faculdade de Engenharia Civil, Universidade Federal de Santa Catarina, Florianópolis,
1999.
XAVIER, A. A. P. Predição de conforto térmico em ambientes internos com
atividade sedentária: Teoria física aliada a estudos de campo. 2005. 251 p. Tese
(Doutorado). Faculdade de Engenharia de Produção e Sistemas, Universidade Federal
de
Santa
Catarina,
Florianópolis,
2005.
ANEXO I
CÓDIGO FONTE DO SOFTWARE DE CONTROLE
Apresenta-se o código fonte, em linguagem C, do controlador fuzzy PI, implementado
no microcontrolador PIC18F4550. Este código 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
**********************************************************/
#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>
E
S
/** 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
************************************************************/
#define LEDAmarelo
#define LEDVermelho
PORTDbits.RD0
PORTDbits.RD1
S
#define VDD 5
#define BOTAO_1
#define BOTAO_2
PORTEbits.RE1
PORTEbits.RE2
/** V A R I A V E I S
G
****************************************/
// variáveis par uso das rotinas de USB
char USB_Out_Buffer[CDC_DATA_OUT_EP_SIZE];
char RS232_Out_Data[CDC_DATA_IN_EP_SIZE];
L
O
B
A
I
S
D
O
S
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
***********************************/
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 ();
S
P
R
I
V
A
//interrupcoes
void HighPriorityISRCode();
void LowPriorityISRCode();
/**
F
U
N
C
O
E
************************************************************/
S
/**********************************************************************
********
* Funcao:
void main(void)
* Entrada:
Nenhuma (void)
* Saída:
Nenhuma (void)
* Descrição:
Função 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 código 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 variável
Num_CAD_bin=ReadADC();
// Inicia a nova Conversão
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 ;
pacote[1] = 11 ;
// STX
// 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); //
buffer
}
// --------------------------------ProcessIO();
envia
o
}
}
/**********************************************************************
********
* Funcao:
static void ConfiguraSistema(void)
* Entrada:
Nenhuma (void)
* Saída:
Nenhuma (void)
* Descrição:
ConfiguraSistema é a rotina de configuração principal do PIC.
*
Seu objetivo é configurar as portas de I/O e os
periféricos
*
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 descrição da
configuração
// 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 Botões 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 informaçoes sobre ADCON1
: pag 262 datasheet.
ADCON1 |= 0x0F;
// configura todas as portas como digitais
//Configura o conversor AD
OpenADC(
//Parâmetro 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
// CONFIGURAÇÃO PWM
TRISC=0b11111001;
LATC= 0x00;
// Set channel C1 and C2 as PWM output.
// 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;
LEDAmarelo =0;
LEDVermelho
// Coloca toda a porta D como saída.
// apaga os LEDs
=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 interrupções
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 interrupçao
INTCONbits.GIE = 1; // enable all interrupts
}//end ConfiguraSistema
/**********************************************************************
********
* Funcao:
void Tratamento_High_Interrupt(void)
* Entrada: Nenhuma (void)
* Saída:
Nenhuma (void)
* Descrição: Função de tratamento das interrupções de ALTA prioridade
*
Nessa função deve-se lembrar de fazer a seguinte lista:
*
1- verificar qual foi a causa da interrupção,
comparando
*
os flags de cada tipo de interrupção.
*
2- tratar a interrupção selecionada.
*
3- limpar o flag que causou a interrupção!!!
Importante
*
para garantir que não ocorrerá uma chamada indesejada ao
sair
*
do tratamento da interrupção.
*
*
Ao sair dessa função é usado o retorno do tipo "retfie
fast",
*
pois esta função é declarada como ALTA prioridade com a
diretiva
*
#pragma interrupt
*
**********************************************************************
*******/
// ATENÇÃO NA SINTAXE de declaração 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)
* Saída:
Nenhuma (void)
* Descrição: Função de tratamento das interrupções de BAIXA prioridade
*
Nessa função deve-se lembrar de fazer a seguinte lista:
*
1- verificar qual foi a causa da interrupção,
comparando
*
os flags de cada tipo de interrupção.
*
2- tratar a interrupção selecionada.
*
Importante
*
sair
*
*
*
*
a diretiva
*
*
3- limpar o flag que causou a interrupção!!!
para garantir que não ocorrerá uma chamada indesejada ao
do tratamento da interrupção.
Ao sair dessa função é usado o retorno do tipo "retfie",
pois esta função é declarada como BAIXA prioridade com
#pragma interruptlow
**********************************************************************
*******/
// ATENÇÃO NA SINTAXE de declaração 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; // Saída anterior do controlador Fuzzy PI
unsigned int control_on = 1; // Variável 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; // Saída do controlador Fuzzy PI
float taxa; // Taxa em que o erro varia
float abs_taxa; // Módulo da taxa
float abs_erro_ant; // Módulo do erro anterior
float out_inc_fuzzy; // Incremento na saída 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 módulo do erro
abs_taxa = fabs(taxa); // Calcula o módulo da derivada do erro
// *** Calcula a saída da base de regras do controlador nebuloso ***
// *** Regiões 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));
// *** Regiões 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));
// *** Regiões IC9 e IC10 ***
else if ((Ki * erro > 1) && (K * abs_taxa < 1))
out_inc_fuzzy = 0.5 * (K * taxa + 1);
// *** Regiões IC11 e IC12 ***
else if ((K * taxa > 1) && (Ki * abs_erro_ant < 1))
out_inc_fuzzy = 0.5 * (Ki * erro + 1);
// *** Regiões IC13 e IC14 ***
else if ((Ki * erro < -1) && (K * abs_taxa < 1))
out_inc_fuzzy = 0.5 * (K * taxa - 1);
// *** Regiões IC15 e IC16 ***
else if ((K * taxa < -1) && (Ki * abs_erro_ant < 1))
out_inc_fuzzy = 0.5 * (Ki * erro - 1);
// *** Região IC17 ***
else if ((Ki * erro > 1) && (K * taxa > 1))
out_inc_fuzzy = 1;
// *** Regiões IC19 ***
else if ((Ki * erro < -1) && (K * taxa < -1))
out_inc_fuzzy = -1;
// *** Regiões IC18 e IC20 ***
else out_inc_fuzzy = 0;
// *** Calcula a saída 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; // Saturação no máximo
if (ciclo < 255) ciclo = 255; // Saturação no mínimo
out_fuzzy = ciclo;
SetDCPWM2(ciclo);
out_fuzzy_anterior = -out_fuzzy;
}
TMR0L = 0xB4;
TMR0H = 0xB3;
// recarrega o timer
LEDVermelho = !LEDVermelho;
LEDAmarelo = !LEDAmarelo;
// apaga os LEDs
INTCONbits.TMR0IF = 0; // limpa o flag de interrupçao
}//end Tratamento_Low_Interrupt
/** V E C T O R
R E M A P P I N G
******************************************/
// Seção necessária para informar ao compilador C18 onde são os novos endereços
//da memória de programa que ele deve alocar as rotinas de tratamento do "reset"
//do microcontrolador e das rotinas de tratamento de interrupção.
//
//ATENÇÃO: COPIAR ESTA SEÇÃO DO CODIGO PARA TODO ARQUIVO
"main.c" DOS PROJETOS QUE
//UTILIZAM O BOOTLOADER PARA GRAVAÇÃO IN-CIRCUIT através do
BOOTLoader.
// Alocação da função de tratamento das interrupções de ALTA prioridade
// no endereço 0x1008 da memória de programa.
//
#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = 0x001008
void _high_ISR (void)
{
_asm goto Tratamento_High_Interrupt _endasm
}
// Alocação da função de tratamento das interrupções de BAIXA prioridade
// no endereço 0x1018 da memória 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 alocação dos endereços
// da memória de programa para seus valores padrão
/** V E C T O R
R E M A P P I
******************************************/
// Rotina necessária para o compilador C18 saber onde é o início do vetor de
// "reset".
// Copiar na íntegra esta parte do código dentro do arquivo "main.c" de TODO
// projeto usado com o Bootloader no PIC.
N
G
// protótipo 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()
#define mLED_Both_On()
#define mLED_Only_1_On()
#define mLED_Only_2_On()
{mLED_1_Off();mLED_2_Off();}
{mLED_1_On();mLED_2_On();}
{mLED_1_On();mLED_2_Off();}
{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;
do
{
delay_count--;
}while(delay_count);
USBResumeControl = 0;
// Set RESUME line for 1-13 ms
}
/*******************************************************************
* 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 *************************************************/