proposta de um clp de plataforma aberta...
TRANSCRIPT
INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE SANTA CATARINA
DEPARTAMENTO ACADÊMICO DE METAL-MECÂNICA MESTRADO PROFISSIONAL EM MECATRÔNICA
EVERSON OSVANIR DA SILVA
PROPOSTA DE UM CLP DE PLATAFORMA ABERTA PARA CONTROLE DISCRETO USANDO LÓGICA
PROGRAMÁVEL
Dissertação submetida ao Programa de Pós-Graduação em Mecatrônica do Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina como parte dos requisitos para a obtenção do título de Mestre em Mecatrônica. Orientador: Roberto Alexandre Dias, Dr.
FLORIANÓPOLIS, 2013
CDD 621.89 S586p Silva, Everson Osvanir da Proposta de um CLP de plataforma aberta para controle discreto usando lógica programável [MP] / Everson Osvanir da Silva; orientação de Roberto Alexandre Dias. – Florianópolis, 2013. 1 v. : il. Monografia de Pós-Graduação (Mecatrônica) – Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina. Inclui referências. 1. CLP. 2. Lógica Programável. 3. Sistemas embarcados. I. Dias, Roberto Alexandre . II. Título.
Sistema de Bibliotecas Integradas do IFSC Biblioteca Dr. Hercílio Luz – Campus Florianópolis Catalogado por: Elaine Santos da Silva CRB 14/1182
PROPOSTA DE UM CLP DE PLATAFORMA ABERTA PARA CONTROLE DISCRETO USANDO LÓGICA
PROGRAMÁVEL
EVERSON OSVANIR DA SILVA
Esta Dissertação foi julgada adequada para obtenção do Título de Mestre em Mecatrônica, e aprovada em sua forma final pela banca examinadora do Programa de Pós-Graduação em Mecatrônica, do Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina.
Florianópolis, 19 de Junho de 2013.
______________________________________ Roberto Alexandre Dias, Dr. - Orientador
______________________________________
Francisco Édson Nogueira de Mélo, MsC. – Coorientador
______________________________________ Roberto Alexandre Dias, Dr. – Coordenador do Curso
Banca Examinadora:
______________________________________ Valdir Noll, Dr. - Membro Interno ao Programa
_____________________________________
Eduardo Augusto Bezerra, Ph.D. - Membro Externo à Instituição
Dedico este trabalho a todos que amo e que me queiram bem.
AGRADECIMENTOS
À minha família pelo apoio e compreensão, em especial ao
meu avô que sempre me incentivou aos estudos.
Aos meus orientadores Roberto e Édson que me ajudaram
a encontrar o caminho certo para a conclusão deste trabalho.
Aos colegas de trabalho do Grupo de Sistemas
Embarcados e Distribuídos e do Projeto “FPGA para Todos”, que
auxiliaram na realização deste trabalho.
Aos professores do Mestrado Profissional de Mecatrônica,
que, pelo empenho na formação de bons profissionais.
Ao colega Cassiano Bonin que me ajudou em uma das
etapas do trabalho.
Por último, e não menos importante, a todos os colegas do
curso pelo companheirismo nesta inesquecível fase de minha
vida.
So close no matter how far It couldn't be much more from the heart
Forever trusting who we are And nothing else matters.
(James Hetfield e Lars Ulrich)
RESUMO
O presente trabalho apresenta uma proposta de um controlador lógico programável (CLP) de plataforma aberta para controle discreto usando lógica programável. O objetivo principal deste trabalho é apresentar como integrar tecnologias embarcadas como sistemas microcontrolados, com poder de processamento suficiente para executar sistemas operacionais abertos, tais como distribuições Linux, e dispositivos lógicos programáveis (Programmable Logic Devices - PLDs) para a expansão de periféricos, que possam ser programados ou reconfigurados conforme os requisitos da aplicação. Esta abordagem possibilita o desenvolvimento de CLPs flexíveis integrando duas tecnologias, uma para processamento de instruções (microcontrolador) e outra que gerenciará os elementos de periferia (PLDs), tais como: interfaces de entrada/saídas digitais, PWMs, temporizadores, etc. A proposta será validada com dois estudos de caso: Um demonstrando a programação do CLP através de linguagem Ladder de um processo de controle discreto e o outro estudo de caso demonstrará o potencial de expansão e reconfiguração de periféricos com o uso de dispositivo de lógica programável.
Palavras-chave: CLP, Lógica Programável, Sistemas Embarcados, Controle de Processos.
ABSTRACT
This paper presents a programmable logic controller (PLC) approach using open platform for discrete control using programmable logic. The main objective of this work is to present how to integrate embedded systems technologies, like microcontroller systems with enough power processing to run open operating systems such as Linux distributions and programmable logic devices (PLDs) for the peripherals expansion that can be programmed or reconfigured according to the application requirements. This approach enables the development of flexible PLCs integrating two technologies, one for processing instructions (microcontroller) and other that manage elements of the periphery (PLDs), such as input/outputs, PWMs, timers, etc. The proposal will be validated using two case studies: One demonstrating the PLC programming using ladder logic for a discrete control process another case study demonstrate the potential for expansion and reconfiguration of peripherals with the use of programmable logic device. Keywords: PLC, Programmable Logic, Embedded Systems, Process Control.
LISTA DE FIGURAS
Figura 1 – Estrutura básica de um CLP. ..................................... 22 Figura 2 – Ciclo de operação de um CLP ................................... 24 Figura 3 – Diagrama funcional de um CLP. ................................ 25 Figura 4 – Exemplo de Programação em Linguagem Ladder. ... 26 Figura 5 – Plataformas mais utilizadas e a previsão de uso. ..... 30 Figura 6 – Principais tipos de dispositivos lógicos programável. 33 Figura 7 – Diagrama de blocos de SPLDs. ................................. 34 Figura 8 – Diagrama de blocos geral de um CPLD. ................... 36 Figura 9 – Estrutura básica de um FPGA. .................................. 37 Figura 10 – Árvore de decisão FPGA versus CPLD. .................. 39 Figura 11 – Modelo geral da proposta. ....................................... 45 Figura 12 – Tela de programação do LDMicro. .......................... 47 Figura 13 – Foto do módulo ConnectCore 9P 9215. .................. 49 Figura 14 – Foto da placa do kit de desenvolvimento da Digi. ... 50 Figura 15 – Foto da placa da Raspberry Pi modelo B. ............... 52 Figura 16 – Exemplo de código em linguagem Ladder. ............. 53 Figura 17 – Código gerado automaticamente pelo LDMicro. ..... 55 Figura 18 – Conjunto dos principais arquivos que fazem parte do HAL da plataforma. ..................................................................... 56 Figura 19 – Aparato físico usado nos testes em laboratório. ..... 57 Figura 20 – Kit didático de CPLD MAXV. ................................... 59 Figura 21 – Integração da Raspberry Pi com o kit de CPLD. ..... 60 Figura 22 – Estrutura de hardware do CPLD.............................. 61 Figura 23 – Protocolo de comunicação. ..................................... 62 Figura 24 – Característica dos dados trocados no protocolo numa operação de escrita. .................................................................... 65 Figura 25 – Característica dos dados trocados no protocolo numa operação de leitura. ..................................................................... 66 Figura 26 – Envio e recebimento de sinais SPI. ......................... 67 Figura 27 – Bloco SPI. ................................................................ 68 Figura 28 – Bloco de controle. .................................................... 69 Figura 29 – Máquina de estados do Bloco de controle. ............ 72 Figura 30 – Modelo de montagem do experimento. ................... 74 Figura 31 – Protótipo do elevador industrial. .............................. 75 Figura 32 – Estrutura do CLP. .................................................... 76 Figura 33 – Máquina de estados do controle do elevador. ........ 78 Figura 34 – Ciclo de operação do CLP. ...................................... 79 Figura 35 – Montagem do sistema. ............................................. 80
10
Figura 36 – Tela do LDMicro com o diagrama Ladder da lógica de controle do elevador industrial. .............................................. 97 Figura 37 – Configurando o LDMicro para gerar um código C ANSI. ........................................................................................... 98 Figura 38 – Convertendo o diagrama em um arquivo em linguagem C. ............................................................................... 99 Figura 39 – Arquivos que compõe o HAL. ................................ 100 Figura 40 – Processo de compilação do HAL na plataforma do CLP. ........................................................................................... 101
LISTA DE TABELAS
Tabela 1 – Fabricantes de PLDs e suas ferramentas de projeto EDA. ............................................................................................ 33 Tabela 2 – Operações mapeadas na solução. ........................... 63 Tabela 3 – Blocos de periféricos mapeados na solução. ........... 64 Tabela 4 – Comportamento da máquina de estados do bloco de controle. ....................................................................................... 69 Tabela 5 – Descrição dos módulos periféricos mapeados na solução com relação aos dados recebidos. ................................ 73 Tabela 6 – comportamento da máquina de estados do elevador industrial. ..................................................................................... 77
LISTA DE SÍMBOLOS
A/D – Analógico/Digital ADC – Analog to Digital Converter API – Application Programming Interface ARM – Advanced RISC Machine ASIC – Application-specific integrated circuit CI – Circuito Integrado CLP – Controlador Lógico Programável CMOS – Complementary metal–oxide–semiconductor CPLD – Complex Programmable Logic Device CPU – Central Processing Unit D/A – Digital/ Analógico DSP – Digital Signal Processing E/S – Entrada/Saída EDA – Electronic Design Automation FIM – Flexible Interface Module FPGA – Field Programmable Gate Array GAL – Generic Array Logic GPIO – General Purpose Input/Output HAL – Hardware Abstract Layer HCPLD – High-Capacity Programmable Logic Device HDL – Hardware Description Language I2C – Inter-Integreted Circuit
IDE – Integrated Development Environment LAB – Logic Array Block LCA – Logic Cell Array MISO – Master Input-Slave Output MMU – Memory Management Unit MOSI – Master Output-Slave Input PAL – Programable Array of Logic PIA – Programmable Interconnetion Array PWM – Pulse-width modulation RISC – Reduced Instruction Set Computer RTL – Register Transfer Level RTOS – Sistema Operacional de Tempo Real SBC – Single Board Computer SO – Sistema Operacional SPLD – Simple Programmable Logic Device TTL – Transistor-Transistor Logic
13
VHDL – Very High Speed Integrated Circuit Hardware Description Language
SUMÁRIO
1 INTRODUÇÃO ............................................................. 16
1.1 Objetivos e Justificativa ................................................ 17
1.1.1 Objetivo Geral ............................................................... 17 1.1.2 Objetivos específicos ................................................... 17 1.1.3 Justificativa ................................................................... 18
1.2 Delimitação do trabalho ................................................ 19 1.3 Estrutura da dissertação .............................................. 19
2 FUNDAMENTO DE CONTROLADORES LÓGICOS PROGRAMÁVEIS ....................................................................... 21
2.1 Principio de funcionamento .......................................... 22 2.2 Ciclo de operação ......................................................... 23 2.3 Programação ................................................................ 25
3 SISTEMAS EMBARCADOS ......................................... 27
3.1 Microcontroladores ....................................................... 28
3.1.1 Arquitetura ARM ........................................................... 30 3.1.2 Sistemas operacionais para plataforma ARM .............. 31
3.2 Dispositivos Lógicos Programáveis ............................. 32
3.2.1 Dispositivo de Lógica Programável Simples ................ 34 3.2.2 Dispositivo Lógico Programável Complexo ................. 35 3.2.3 Matriz de portas lógicas programáveis em campo ...... 36 3.2.4 Comparação FPGA versus CPLD ................................ 38
4 DEFINIÇÃO E TRABALHOS RELACIONADOS .......... 40
4.1 Definição ....................................................................... 40 4.2 Trabalhos relacionados ................................................ 40 4.3 Discussão ..................................................................... 42
5 SOLUÇÃO PROPOSTA ............................................... 44
5.1 Estudo de caso 1 – Camada de abstração de hardware para interpretação de lógica Ladder ........................................... 45
5.1.1 Ferramenta LDMicro..................................................... 46 5.1.2 Plataformas de hardware ............................................. 47
15
5.1.2.1 ConnectCore 9P 9215 .................................................. 48 5.1.2.2 RaspBerry Pi ................................................................. 50
5.1.3 Porte do LDMicro para as plataformas......................... 53 5.1.4 Validação ...................................................................... 57
5.2 Estudo de caso 2 – Integração do dispositivo microcontrolado e o dispositivo lógico programável ................... 58
5.2.1 Implementação da programação do CPLD .................. 60 5.2.2 Protocolo de comunicação ........................................... 61 5.2.3 Bloco SPI ...................................................................... 66 5.2.4 Bloco de controle .......................................................... 68 5.2.5 Bloco de periféricos ...................................................... 72 5.2.6 Validação ...................................................................... 74
5.2.6.1 Estrutura do elevador ................................................... 74 5.2.6.2 Estrutura do CLP .......................................................... 76 5.2.6.3 Lógica Ladder, ciclo de operação e execução do programa ..................................................................................... 77
6 CONCLUSÃO E TRABALHOS FUTUROS .................. 81
6.1 Trabalhos futuros .......................................................... 82
REFERÊNCIAS BIBLIOGRÁFICAS ............................................ 84 APÊNDICES ................................................................................ 87
APÊNDICE A – Diagrama Ladder da lógica de controle do elevador industrial ....................................................................... 88 APÊNDICE B – Tutorial de uso do HAL para o CLP .................. 96
1 INTRODUÇÃO
Os primeiros sistemas de automação operavam por meio de sistemas eletromecânicos, com relés e contatores. Neste caso, os sinais acoplados à máquina ou equipamento a ser automatizado eram acionados por circuitos lógicos a relés que disparavam as cargas e atuadores (PINTO, 2008, p. 31) (FRANCHI; CAMARGO, 2008, p. 21). A estrutura física desses sistemas é demasiadamente pesada e pouco duradoura, necessitando constantes reparos. Além disso, esse sistema é pouco flexível no sentido de alterar a lógica do processo e/ou adicionar novas funcionalidades.
O surgimento da tecnologia dos Circuitos Integrados (CIs) possibilitou novos rumos para a automação de processos na indústria. Isto viabilizou o desenvolvimento de uma nova geração de sistemas de controle capazes de executar funções mais complexas e sofisticadas. “Em comparação aos relés, os CIs baseados nas tecnologias TTL ou CMOS são muito menores, mais rápidos e possuem uma vida útil muito maior” (FRANCHI; CAMARGO, 2008, p. 21). Mas ainda assim, como no caso dos sistemas eletromecânicos, esse tipo de tecnologia é pouco flexível, pois normalmente a lógica de controle é definida permanentemente pela interligação elétrica.
Por certo tempo, os sistemas de automação citados tiveram uma grande importância no crescimento da produção industrial. Entretanto, a necessidade de mudanças cada vez mais constante na linha de produção das indústrias para suprir a demanda do mercado fez com que novas tecnologias mais flexíveis surgissem. Foi nesse cenário que surgiram os Controladores Lógicos Programáveis (CLPs).
As primeiras aplicações com CLPs aconteceram na Hydronic Division da General Motors, em 1968, devido à grande dificuldade de mudar a lógica de controle de painéis de comando a cada mudança na sua linha de montagem (PINTO, 2008, p. 32) (FRANCHI; CAMARGO, 2008, p. 22).
Os CLPs são equipamentos eletrônicos utilizados em sistemas de automação flexível. São ferramentas de trabalho muito úteis e versáteis para aplicações em sistemas de acionamentos e controle, e por isso são utilizados em grande escala no mercado industrial. Permitem desenvolver e alterar
17
facilmente a lógica para acionamento das saídas em função das entradas. Desta forma, podem-se associar diversos sinais de entrada para controlar diversos atuadores ligados nos pontos de saída.
Esse avanço dos sistemas de automação industrial só foi possível com o avanço tecnológico da eletrônica que possibilitou o desenvolvimento de CIs cada vez mais versáteis, robustos, com mais capacidade de processamento e armazenamento de dados em uma estrutura mais compacta e, principalmente, com capacidade de programação e reprogramação de suas funcionalidades através de software (ou firmware, como é chamado o software para sistemas embarcados).
1.1 Objetivos e Justificativa
1.1.1 Objetivo Geral
Empregar um dispositivo microcontrolado executando um sistema operacional Linux de uso geral integrado a um dispositivo de lógica programável para implementação de um controlador lógico programável modular, expansível e de baixo custo.
1.1.2 Objetivos específicos
Para o trabalho proposto estabeleceu-se os seguintes objetivos específicos:
a) Explorar plataformas microcontroladas para controle de
processos industriais discretos; b) Implementar o porte de um interpretador Ladder de
código aberto em plataforma Linux; c) Explorar o uso de lógica programável para expansão de
periferia da plataforma microcontrolada, de forma modular e programável;
18
d) Avaliar a aplicação de sistema microcontrolado integrado à lógica programável para controle de processos industriais discretos.
1.1.3 Justificativa
Tendo em vista que os CLPs já são consagrados na indústria e seu uso é indispensável para automação dos processos industriais, esta dissertação propõe o desenvolvimento de um CLP de plataforma aberta para controle de processos discretos utilizando lógica programável para expansão de periféricos.
Esta proposta apresentará uma unidade de processamento baseada em um microcontrolador que se encarregará de executar as instruções de diagramas Ladder para programação de controle de processos industriais e um dispositivo lógico programável que se encarregará de gerenciar os elementos periféricos como interfaces de entradas e saídas digitais e PWMs que controlam os processos externos.
O foco do presente trabalho é explorar os recursos de dispositivos microcontrolados de baixo custo (tais como, Single Board Computers – SBCs) com poder de processamento suficiente para rodar sistemas operacionais (SO) de uso geral, tal como o Linux, aproveitando os recursos de softwares e bibliotecas de código aberto disponíveis nesses SOs para desenvolvimento de aplicações no âmbito acadêmico envolvendo controle de processos discretos. Além disso, integrar um dispositivo de lógica programável para expansão de periféricos de forma modular e configurável, possibilitando o emprego de outros periféricos de alta velocidade e personalizado pelo desenvolvedor e a inclusão de processamento rápido em hardware, que podem ser implementados em linguagem de descrição de hardware.
A proposta será validada através de dois estudos de caso: Um demonstrando o uso da linguagem Ladder, específica para programação da lógica de processos em CLPs, em um sistema microcontrolado controlando um processo simples e outro estudo de caso demonstrando o potencial de expansão e configuração de periféricos com o uso de dispositivo de lógica programável.
19
1.2 Delimitação do trabalho
Alguns assuntos, apesar da relação com o tema do trabalho, não foram abordados ou desenvolvidos, devido à demanda de tempo extra ou à depreciação da objetividade do texto. Não fazem parte do escopo da presente pesquisa os seguintes temas:
e) Desenvolvimento de um interpretador Ladder: Apesar de
que este assunto faz parte de um dos estudos de caso, este trabalho não contempla este desenvolvimento. Para isso foi pesquisada e utilizada uma ferramenta de criação de diagramas Ladder de código aberto que possibilitasse a portabilidade lógica para um código em linguagem C ANSI;
f) Condicionamento dos sinais de entrada e saída do CLP: O escopo desse trabalho não visa a desenvolver o hardware completo de um CLP, portanto, se limita a desenvolver somente a parte lógica do CLP utilizando recursos de hardware prontos, tais como, módulos microcontrolados e kit didático de lógica programável.
1.3 Estrutura da dissertação
Esta dissertação é dividida em seis capítulos. O primeiro capítulo trata da introdução ao tema, delimitando o escopo do projeto, justificando o estudo do tema e expondo os objetivos e limitação do trabalho. No segundo capítulo é apresentada uma fundamentação sobre controladores lógicos programáveis, bem como o seu princípio de funcionamento, ciclo de operação e programação.
No terceiro capítulo é apresentada uma breve descrição sobre sistemas embarcados, abordando o atual estado da arte sobre microcontroladores e sistemas operacionais embarcados e sobre os dispositivos lógicos programáveis e seus principais tipos.
20
No quarto capítulo é abordada a definição do problema, bem como um resumo de alguns trabalhos relacionados que motivaram o desenvolvimento desta pesquisa.
No quinto capítulo é explanada a solução proposta para o problema definido no capítulo anterior. É neste capitulo que serão apresentados os estudos de caso propostos neste trabalho. Os resultados serão descritos neste capítulo também e serão divididos dentro dos subcapítulos relacionados aos estudos de caso.
Por último, no sexto capítulo, encontram-se a conclusão dessa dissertação e sugestões para trabalhos futuros.
2 FUNDAMENTO DE CONTROLADORES LÓGICOS PROGRAMÁVEIS
Assim como os microcontroladores e os computadores pessoais que são máquinas eletrônicas de processamento de dados, os Controladores Lógicos Programáveis (CLPs) são específicos para executar instruções que controlam dispositivos, máquinas e operações de processos (PEREIRA, 2003, p. 4).
Os primeiros CLPs surgiram por volta de 1968 quando a General Motors® solicitou para a indústria eletrônica uma solução para substituir os painéis de controle que usavam relés para as operações de controle e acionamento de processos. Estes painéis estavam ficando grandes e complexos demais para o desenvolvimento e manutenção das plantas industriais (PEREIRA, 2003, p. 4) (PINTO, 2008).
Com o CLP, as indústrias conseguiram melhorar os índices
de escalabilidade, projeto e manutenção das plantas industriais. A arquitetura básica de um CLP é composta de um
processador, barramentos de controle, dados e endereços, memórias de operação e de usuário, entradas e saídas e drivers de corrente (GEORGINI, 2008, p. 55) (PINTO, 2008).
Um dos componentes mais importantes é a estrutura do processador e da memória. Este conjunto coordena as entradas e saídas, controle de processos e os programas de usuário. O processador é responsável pelo gerenciamento total do sistema, controlando os barramentos de endereços, de dados e de controle (GEORGINI, 2008, p. 54).
Além de geralmente serem específicos para processos industriais, os CLPs costumam ter drivers de corrente robustos para acionamento de máquinas elétricas e ter uma excelente proteção contra interferências eletromagnéticas, comuns no ambiente hostil em que são instalados.
22
2.1 Principio de funcionamento
A estrutura de um CLP pode ser dividida em três partes: entrada, processamento e saída (Figura 1).
ESTRUTURA BÁSICA DE UM CLP
Unidade Central
de
Processamento
E
N
T
R
A
D
A
S
S
A
Í
D
A
S
Figura 1 – Estrutura básica de um CLP.
Os sinais de entrada e saída dos CLPs podem ser digitais ou analógicos. Existem diversos tipos de módulos de entrada e saída que se adéquam às necessidades do sistema a ser controlado. Isso vai depender do modelo e do fabricante.
Os módulos de entrada e saídas são compostos de grupos de bits, associados em conjunto de 8 bits (1 byte) ou conjunto de 16 bits, de acordo com o tipo da Unidade Central de Processamento (do inglês, Central Processing Unit – CPU).
As entradas analógicas são módulos conversores Analógico/Digital (A/D), que convertem um sinal de entrada em um valor digital, com uma resolução de normalmente de 12 bits (4096 combinações).
As saídas analógicas são módulos conversores D/A, ou seja, um valor binário é transformado em um sinal analógico.
A CPU é o “cérebro” do Sistema. Ela é constituída por um circuito eletrônico composto de microprocessadores e memórias programáveis através de linguagens específicas para programação da lógica de CLPs, realizada de modo simplificado e amigável pelo usuário, através de um microcomputador.
23
A CPU é a inteligência do processo de automação, pois ela tem a capacidade de identificar e compreender os sinais de entrada provenientes dos dispositivos de campo conectados em seus terminais (tais como, sensores, chaves e botões) e, de acordo com uma programação (feita pelo usuário), enviar sinais elétricos aos dispositivos de campo conectados nos terminais de saída (tais como, contatores e sinalizadores), fazendo com que os mesmos atuem no processo. Disponibiliza ao programador funções especiais como temporização, contagem e cálculos matemáticos.
2.2 Ciclo de operação
O ciclo de operação de um CLP pode ser dividido em três principais etapas:
Varredura das Entradas: A CPU lê todas as entradas e guarda as informações em uma memória especial, denominada Memória Imagem de Entrada;
Varredura do Programa: As informações da Memória Imagem de Entrada são processadas de acordo com o programa realizado pelo usuário, e de acordo com a lógica do programa muda os estados das saídas e guarda estas informações em outra memória especial denominada Memória Imagem de Saída;
Varredura das Saídas: As saídas são atualizadas de acordo com a Memória Imagem de Saída.
A Figura 2 exemplifica o processo do ciclo de operação de um CLP.
24
Inicialização
Leitura das entradas
Atualização da
memória imagem das
entradas
Processa programa
Atualizar as saídas
Atualização da
memória imagem das
saídas
Figura 2 – Ciclo de operação de um CLP
Fonte: Adaptado de PINTO, 2008.
Esta rotina de operação, chamada de varredura ou scan, é executada ciclicamente pela CPU. O tempo de cada ciclo depende do tamanho do programa e do número de pontos de Entradas e Saídas (E/S), este tempo, porém tem de ser o menor possível (poucos milissegundos), e varia de CPU para CPU (dados construtivos).
25
Conforme explicado até aqui, a Figura 3 mostra o diagrama funcional de um CLP.
CPU
E
N
T
R
A
D
A
S
S
A
Í
D
A
S
V- V-
V+
V+
Computador com software
apropriado para programar
e monitorar o CLP
Figura 3 – Diagrama funcional de um CLP.
2.3 Programação
A programação do CLP é feita por um computador através de um software apropriado, que normalmente é fornecido pelo fabricante do controlador. Este software vai permitir ao usuário programar a lógica de funcionamento do processo na CPU do CLP. Existem várias linguagens de programação que são específicas para CLPs, tais como: lista de instruções, linguagem de blocos, texto estruturado, Ladder e blocos lógicos.
Normalmente essas linguagens são de alto nível criadas especialmente para técnicos e engenheiros que não possuem conhecimento aprofundado em programação. Desta forma, a linguagem que teve maior aceitação na indústria e ainda é a mais utilizada é a Linguagem Ladder, isto se dá porque ela se assemelha com os símbolos utilizados pelos eletricistas nos projetos de comandos elétricos.
Segundo Georgini (2008, p. 84), “A primeira linguagem criada específica para programação de CLPs foi a Linguagem Ladder”. Ela é baseada em símbolos semelhantes aos encontrados nos esquemas elétricos, como: contatos e bobinas.
26
Foi determinante para a aceitação do CLP por técnicos e engenheiros acostumados com os sistemas de controle a relés (GEORGINI, 2008).
O nome da linguagem foi escolhido devido à representação da linguagem se parecer com uma escada (ladder), onde duas barras verticais paralelas são interligadas pelas linhas horizontais que representam a lógica de controle (rungs) (GEORGINI, 2008). A Figura 4 mostra um pequeno exemplo da linguagem.
Figura 4 – Exemplo de Programação em Linguagem Ladder.
Fonte: Georgini, 2008, p. 84.
Atualmente, existem outras instruções além das mostradas na Figura 4. Com o tempo surgiram instruções de detecção de borda, contatos de comparação, temporizadores, contadores, blocos de processamento para realização de operações lógicas e aritméticas e manipulação de dados (GEORGINI, 2008).
3 SISTEMAS EMBARCADOS
Ao contrário de um computador de propósito geral, que pode executar diversos programas, desempenhando diversas funções, os sistemas embarcados são dispositivos considerados de propósitos específicos ou dedicados. Eles são formados basicamente pelos mesmos componentes de um computador: processador, memória, dispositivo de armazenamento, interfaces e demais componentes. Porém, a principal diferença é que, ao contrário de um computador, eles se limitam a executar bem uma única tarefa ou poucas tarefas. Desta forma, em um projeto com um dispositivo embarcado, devem-se levar em conta os seus recursos de hardware, tais como, processamento e memória, que são limitados.
Outro ponto importante a ser destacado em projetos envolvendo sistemas embarcados é a confiabilidade. Um sistema que executa um conjunto de tarefas específicas para uma determinada aplicação deve fornecer maior qualidade e confiabilidade do que um sistema computacional de propósito geral, até porque esse sistema pode ser desenvolvido para aplicações críticas que exija um grau de credibilidade muito alto. Como exemplos de aplicações podem ser citados as de controle e automação industrial, sistemas automotivos, sistemas de controle de aeronaves, sistemas de monitoração e gerenciamento de variáveis críticas (energia elétrica, temperatura, pressão), sistemas de segurança eletrônica, entre inúmeras outras.
O núcleo de um sistema embarcado é o microprocessador. É nele que são processadas as funções de aritmética e tomadas de decisões para execução de uma tarefa específica. Em um sistema embarcado, o microprocessador não é um elemento separado, ele faz parte de componentes muito importantes como, por exemplo, microcontroladores e DSPs (Digital Signal Processing ou, em português, Processador de sinais digitais), que agregam, além do processador, outros elementos periféricos essenciais para o gerenciamento e controle de sistemas dedicados.
Em soluções embarcadas, os microcontroladores são os componentes mais utilizados e podem ser encontrados em quase todos os dispositivos eletrônicos digitais. É possível encontrar no
28
mercado microcontroladores de diversos modelos, que se diferenciam pela capacidade de processamento, memória e quantidade de periféricos, variando o custo do componente. Isto possibilita ao projetista de sistemas embarcados uma maior flexibilidade na escolha do microcontrolador que atenda aos requisitos de projeto, evitando a subutilização do componente e, consequentemente, reduzindo o custo final.
Outros dispositivos bastante utilizados em projetos de sistemas embarcados são os PLDs. Esses dispositivos são específicos para criação de lógica digital. Entende-se por PLD todo o dispositivo que implementa lógica digital programada pelo usuário, não apresentando uma função lógica definida, até que sejam configurados. Devido a isto, têm-se os tipos de dispositivos lógicos que se diferenciam basicamente pela sua capacidade de elementos lógicos e suas características construtivas, tais como, SPLDs, CPLD e FPGAs. A grande vantagem dos PLDs é que toda a lógica digital programada pelo usuário é executada diretamente em hardware, tornando o processo mais eficiente em relação ao conjunto de instruções que são controladas por um microprocessador, como acontece em arquiteturas microcontroladas.
Neste capítulo será apresentada uma breve descrição dos dispositivos e tecnologia de hardware que foram utilizados para elaboração dos estudos de casos apresentados neste trabalho.
3.1 Microcontroladores
A principal classificação de um microcontrolador é dada pelo tamanho da palavra de dados que seu processador pode suportar que pode ser de 8, 16, 32 ou 64 bits. Os microcontroladores de 8 bits ainda são os mais utilizados no desenvolvimento de aplicações que não demandam processamento e memória muito alto pela sua boa relação custo x benefício. Tais microcontroladores podem ser encontrados em diversas arquiteturas de 8 bits, sendo os mais populares: a família 8051, introduzida inicialmente pela Intel e hoje produzida por diversos fabricantes; a família AVR da ATMEL e; a família PIC da Microchip Tecnology.
29
Os microcontroladores de 16 e, principalmente os de 32 e 64 bits possuem mais vantagens e são superiores aos de 8 bits e, atualmente, dominam o mercado da tecnologia. Hoje é possível encontrá-los em videogames, celulares, smartphones, tablets, entre outros aparelhos que agregam muitas funcionalidades e dependem de um maior processamento. Entre os microcontroladores de 16 bits tem-se como exemplo a família PIC de 16 bits, da Microchip e, para 32 e 64 bits, têm-se os microcontroladores baseados na arquitetura ARM, produzidos por vários fabricantes, e os Coldfire, produzidos pela Freescale SemiConductor.
Entre os microcontroladores e arquiteturas citadas, este trabalho dará destaque aos microcontroladores baseados na arquitetura ARM de 32 bits, devido à necessidade de um dispositivo embarcado mais robusto, que suporte um sistema operacional de uso geral, para possibilitar a execução das pilhas de protocolos necessárias para elaboração dos estudos de casos apresentados neste trabalho.
Outro motivo pela escolha desta arquitetura de 32 bits, e não de outras, deve-se pela grande popularização do ARM devido às suas características atraentes, que incluem um design simples, alta velocidade, grande diversidade de modelos e fabricantes e grande quantidade de softwares disponíveis, entre outras.
Numa pesquisa elaborada pelo artigo (LINUX FOR DEVICES, 2007) do portal na internet <http://www.Linuxfordevices.com/>, que trata de assuntos voltados a dispositivos embarcados com o sistema operacional Linux, mostrou-se a tendência do uso de plataformas baseadas nas arquiteturas mais utilizadas, principalmente de 32 bits. Esta pesquisa não é tão recente, feita no ano de 2007, entretanto mostrava o crescimento do uso de microcontroladores baseados na arquitetura ARM em dispositivos embarcados. Hoje é sabido que esta arquitetura se consolidou no mundo da tecnologia e incorpora os diversos dispositivos voltados para o mercado comercial e industrial. Na Figura 5, são apresentadas as plataformas mais utilizadas no ano de 2007 e a previsão de uso para os dois anos seguintes.
30
Figura 5 – Plataformas mais utilizadas e a previsão de uso.
Fonte: LINUX FOR DEVICES, 2007.
3.1.1 Arquitetura ARM
Os microcontroladores e microprocessadores Advanced RISC Machine (ARM) são unidades centrais de processamento (CPUs – Central Processing Unit) de 32 bits baseadas na arquitetura Reduced Instruction Set Computer (RISC – em português, Computador com Conjunto Reduzido de Instruções).
Essas importantes CPUs surgiram no início dos anos 80, no século passado, a partir de um projeto inovador de um fabricante britânico de computadores chamado Acorn Computer Group. Essas CPUs foram originalmente concebidas como um processador para computadores pessoais, sendo que suas primeiras versões comerciais (ARM2 e ARM3) foram empregadas nos primeiros computadores RISC (Archimedes 300, 400 e 500) fabricados pela Acorn (PEREIRA, 2007, p. 17; ARM, 2013).
31
Em 1990, a Acorn Computer group, a Apple Computer e a VLSI Technology uniram-se para formar a Joint Venture ARM Limited, e em 1991 foi lançada a primeira versão embarcada comercial da CPU ARM, o ARM6TM, juntamente com o microprocessador ARM610 (PEREIRA, 2007, p. 17).
“Os principais conceitos por trás da arquitetura ARM são a simplicidade, baixo custo, pequeno consumo e modularidade: as CPUs ARM foram projetadas para serem simples, baratas e integradas aos mais diversos periféricos, atendendo a diversos perfis de aplicação” (PEREIRA, 2007, p. 18).
Atualmente, a ARM Limited não fabrica chips, apenas licencia a propriedade intelectual para o uso de suas CPUs por outros fabricantes de microcontroladores e microprocessadores.
Diversas variações das CPUs ARM estão disponíveis, diferenciadas pela versão da arquitetura e pela família às quais pertencem. Atualmente, a arquitetura ARM está na oitava versão, mas somente as versões 4 e superiores continuam sendo apoiada pela ARM Limited.
3.1.2 Sistemas operacionais para plataforma ARM
Um sistema operacional (SO) é formado por um conjunto de programas e rotinas computacionais que têm como objetivo criar uma camada de abstração entre o usuário e o hardware propriamente dito. Eles controlam e gerenciam o hardware e os recursos de aplicativos de uma plataforma computacional. Um SO estabelece normalmente uma estrutura e protocolos para que as aplicações possam utilizar os recursos do hardware e, frequentemente, inclui diversas funções gerais Application Programming Interfaces (APIs) que podem ser empregadas pelas aplicações para trocar informações com o sistema operacional e com outras aplicações em execução.
Estão disponíveis dois tipos básicos de SO para a plataforma ARM: sistemas operacionais de uso geral e sistemas operacionais de tempo real (RTOS) (PEREIRA, 2007).
Os Sistemas operacionais de uso geral são voltados à execução de múltiplas aplicações em que os tempos de resposta a eventos não são críticos. Eles normalmente necessitam de uma unidade de gerenciamento de memória, conhecido como
32
MMU, e exigem maiores recursos do processador assim como maior quantidade de memória disponível. Esses sistemas se assemelham aos sistemas operacionais tradicionais utilizados em computadores e, por isso, são muito utilizados em dispositivos portáteis como smartphones, tablets, etc. Como exemplos desses sistemas, podem-se destacar: Windows CE
® e
Windows Mobile®, versões embarcadas de distribuições Linux,
CLinux, Android, Symbian OS, entre outros. Por conseguinte, os sistemas operacionais de tempo real
são voltados à execução de processos de controle em que o tempo de resposta a eventos é crítico. Eles são mais utilizados em aplicações embarcadas, especialmente de controle de processos e equipamentos em que a comunicação com o usuário é mais limitada. Esses sistemas costumam consumir muito menos recursos do processador e podem ser utilizados em equipamentos com quantidade de memória muito menor do que os outros sistemas citados. Como exemplos desses, destacam-se: IAR PowerPac da IAR, RL-ARM da Keil, OSEK, Inferno, entre outros.
3.2 Dispositivos Lógicos Programáveis
Os dispositivos lógicos programáveis (PLDs) são circuitos integrados que podem ser configurados pelo próprio usuário, não apresentam uma função lógica definida, até que sejam configurados. Possuem como principal característica a capacidade de programação das funções lógicas pelo usuário, eliminando-a do processo de fabricação do chip, facilitando assim as prováveis mudanças de projeto. Em comparação com outras tecnologias de circuitos integrados digitais os dispositivos de lógica programável apresentam um ciclo de projeto muito curto e custos muito baixo (TEIXEIRA, 2002).
Segundo da Costa (2006), Os PLDs foram os dispositivos eletrônicos que possibilitaram a implementação da lógica flexível e reconfigurável. Esses dispositivos lógicos possuem como sua principal característica a capacidade de programação pelo usuário, eliminando partes do processo de fabricação do chip tradicional e facilitando desta forma as mudanças de projeto. Para um bom entendimento do conceito de lógica flexível
33
considera-se como tal, todo o circuito de lógica digital configurado pelo usuário final. Segundo Tocci (2007, p. 730), os PLDs podem ser descritos como pertencendo a três tipos diferentes: dispositivos lógicos programáveis simples (simple programmable logic devices – SPLDs), dispositivos lógicos programáveis complexos (complex programmable logic devices – CPLDs) ou matrizes de portas programáveis em campo (field programmable gate arrays – FPGAs). Esses dois últimos, costumam ser chamados de dispositivos lógicos programáveis de alta capacidade (high-capacity programmable logic devices – HCPLDs). A Figura 6 apresenta tipos categorias de PLDs.
HCPLDs
PLDs
CPLDs FPGAsSPLDs
Figura 6 – Principais tipos de dispositivos lógicos programável.
Os PLDs são oferecidos no mercado de semicondutores
por diversos fabricantes. Cada um fornece uma família de PLDs dos tipos citados anteriormente, juntamente com a ferramenta Electronic Design Automation (EDA) de apoio ao projeto, que permite desenvolver e configurar os projetos. Na Tabela 1 é apresentada a lista dos principais fabricantes de PLDs e suas ferramentas de projeto EDA.
Tabela 1 – Fabricantes de PLDs e suas ferramentas de projeto EDA.
Fonte: Adaptado de DA COSTA et al, 2011, p. 31-32.
Fabricante Ferramenta de projeto –
EDA Website
Achronix Semiconductor
Corporation
Achronix CAD Environment (ACE)
http://www.achronix.com
34
Fabricante Ferramenta de projeto –
EDA Website
Microsemi Corporation (antiga Actel Corporation)
Libero IDE http://www.microsemi.co
m
Altera Corporation
Quartus II http://www.altera.com
Atmel Corporation
Inregrated Development System (IDS)
http://www.atmel.com
Cypress Semiconductor
Warp http://www.cypress.com
Lattice Semiconductor
Corporation ispLEVER
http://www.latticesemi.com
QuickLogicCorporation
QuickWorks http://www.quicklogic.co
m
Xilinx Vivado e ISE http://www.xilinx.com
3.2.1 Dispositivo de Lógica Programável Simples
O SPLD foi o PLD que surgiu inicialmente e, geralmente, pode substituir até dez CIs de função fixa e suas interconexões, dependendo dos tipos de funções e do SPLD específico. As principais SPLDs são a PAL (programable array of logic) e GAL (generic array logic). Um dispositivo PAL pode ser programado uma vez. Ele consiste de um arranjo programável de portas AND e um arranjo fixo de portas OR, como mostra a Figura 7.a. Um dispositivo GAL é basicamente um dispositivo PAL que pode ser programado várias vezes. Ele consiste de um arranjo programável de portas AND e um arranjo fixo de portas OR com saídas programáveis, como mostra a Figura 7.b.
Figura 7 – Diagrama de blocos de SPLDs.
35
Fonte: FLOYD, 2007, p. 40.
3.2.2 Dispositivo Lógico Programável Complexo
Os CPLDs costumam combinar uma série de dispositivos do tipo PAL no mesmo chip. Basicamente, um CPLD é a interligação de uma estrutura programável de múltiplos SPLDs (TOCCI, 2007, p. 731) (FLOYD, 2007, p. 39-40) (DA COSTA et al, 2011, p. 28). Isto se deu porque o nível de complexidade dos circuitos integrados SPLDs não podia se expandido para permitir a implementação de funções lógicas mais complexas. Portanto, “em 1984, surgem os primeiros circuitos integrados CPLDs, desenvolvidos pela Altera Inc., os quais proporcionavam uma capacidade equivalente a cerca de 50 SPLDs” (DA COSTA et al, 2011, p. 28).
O bloco básico de um CPLD consiste em blocos de arranjos lógicos (logic array blocks – LABs ou também chamado de macrocélulas) e em arranjos de interconexões programáveis (programmable interconnetion arrays - PIA), como mostra o diagrama de blocos geral de um CPLD da Figura 8. Cada arranjo lógico é equivalente a um SPLD.
36
Figura 8 – Diagrama de blocos geral de um CPLD.
Fonte: FLOYD, 2007, p. 40.
3.2.3 Matriz de portas lógicas programáveis em campo
Segundo da Costa et al (2011, p. 29), “em 1985, a empresa Xilinx anunciou uma nova arquitetura de circuitos integrados baseados em lógica programável, rompendo radicalmente com as arquiteturas baseadas em PLDs. Essa nova arquitetura, denominada Logic Cell Array (LCA), seria o protótipo do que desde então se convencionou chamar de FPGA”. Sua estrutura é composta por uma matriz de blocos lógicos cercados por blocos de entrada e saída, todos esses independentes, e por um conjunto de interconexões programáveis que permitem a interconexão arbitrária dos blocos. A Figura 9 apresenta a estrutura básica de um FPGA.
37
Figura 9 – Estrutura básica de um FPGA.
Fonte: FLOYD, 2007, p. 41.
“Os blocos lógicos em um FPGA não são complexos como os LABs em um CPLD, porém, geralmente eles existem em maior número. Quando os blocos lógicos são relativamente simples, a arquitetura do FPGA é denominada grão fino (fine-graned). Quando os blocos lógicos são maiores e mais complexos, a arquitetura é denominada grão grosso (coarse-graned). Os blocos de entrada e saída estão nas bordas da estrutura e proporcionam acesso individualmente selecionável de entrada, saída ou bidirecional ao mundo externo. A matriz de interconexões programáveis distribuídas provê as interconexões de blocos lógicos e as conexões para as
38
entradas e saídas. FPGAs de grande capacidade podem ter dezenas de centenas de blocos lógicos, além de memória e outros recursos” (FLOYD, 2007, p. 41).
3.2.4 Comparação FPGA versus CPLD
As diferenças entre FPGAs e CPLDs nem sempre são óbvias. Às vezes chegam a ser um tanto obscuras, devido aos fabricantes que lançam constantemente novos aperfeiçoamentos de arquitetura e divulgam informações confusas para vender mais produtos (TOCCI, 2007, p. 730). Entretanto, pode-se dizer que os circuitos integrados dos FPGAs permitem alcançar níveis de integração muito superiores aos CPLDs, porque é maior a complexidade das suas arquiteturas de roteamento e de implementação lógica, passando cada ligação normalmente por vários comutadores (DA COSTA et al, 2011, p. 30). Nos CPLDs são tipicamente simples, tendo sua lógica implementada usando basicamente dois planos lógicos AND e OR, com portas de elevado número de entradas. Enquanto que nos FPGAs a lógica é implementada empregando múltiplos planos e portas com reduzido número de entradas, proporcionando implementações mais compactas.
Existem muitos fatores que vão determinar a escolha do dispositivo CPLD ou FPGA que melhor se adapte a uma determinada aplicação. Na Figura 10 é apresentada uma árvore de decisão publicada por da Costa et al (2007, p. 31) que inclui alguns critérios básicos consideráveis quando se pretende escolher entre um desses dispositivos.
39
Início
Velocidade
Densidade
Aplicação
Consumo
Roteamento
Tecnologia
FPGA CPLD
Muito elevada,
não previsível
Elevada,
previsível
Uso intensivo
de lógica
combinacional
Global, atraso fixo
A maior
possível
Uso intensivo
de registros
Muito baixo
Segmentado,
atraso variável
SRAM
(reconfigurável)
Flash/EEPROM
(reprogramável)
Figura 10 – Árvore de decisão FPGA versus CPLD.
Fonte: adaptado de DA COSTA et al, 2007, p. 31.
4 DEFINIÇÃO E TRABALHOS RELACIONADOS
4.1 Definição
As indústrias de uma maneira geral necessitam automatizarem suas linhas de produção e os processos de manufatura usam Controladores Lógicos Programáveis (CLPs).
Os CLPs são equipamentos eletrônicos de processamento de dados específicas para executar instruções que controlam outros dispositivos, máquinas e operações de processos (PEREIRA, 2003, p. 4).
Os CLPs foram projetados para reduzir o elevado custo envolvido na substituição de um sistema de controle de máquinas baseado em painéis de comando acionados por relés. A lógica de controle dos processos automatizados pelos CLPs é normalmente programada por uma linguagem de alto nível, sendo que a mais utilizada é a linguagem de programação Ladder, padronizada na norma IEC 61131-3 (a norma pode ser comprada diretamente no site da International Electrotechnical Commission – IEC em: http://www.iec.ch/).
Sabe-se também que um CLP é composto basicamente por um processador (CPU), memórias e interfaces de entrada e saída para interação com o mundo externo. Com isso, muitas pesquisas surgiram com o intuito de desenvolver CLPs de baixo custo e de arquitetura aberta utilizando microcontroladores e/ou dispositivos lógicos programáveis, como alternativas baratas para automação de processos em contraponto as soluções de arquitetura fechada e caras de diversos fabricantes de CLPs.
Para isso, buscou-se apresentar um estudo sobre as plataformas de desenvolvimento de software e hardware para controle de processos industriais visando integrar dispositivos eletrônicos como sistemas microcontrolados e dispositivos lógicos programáveis para implementação de controladores lógicos programáveis de arquitetura aberta e de custo relativamente baixo.
4.2 Trabalhos relacionados
41
Vários trabalhos contribuem para a implementação de CLPs baseados em sistemas embarcados com plataforma aberta. Entre os principais podem-se destacar os apresentados abaixo: Em Hidalgo et al (2008) foi apresentado o desenvolvimento de um conversor de linguagem Ladder para código assembly de um microcontrolador de 8 bits da família 8051 da ATMEL com o objetivo de implementar controladores lógicos programáveis de baixo custo que possam ser utilizados em micro e pequenas empresas.
Em Westhues (2010), foi desenvolvido um compilador de código aberto que permite gerar código nativo para microcontroladores PIC16 e AVR a partir de um diagrama Ladder. Este compilador, denominado LDMicro, permite a implementação de CLPs de baixo custo utilizando microcontroladores relativamente baratos no mercado e, ainda, permite que qualquer pessoa da área possa desenvolver o seu próprio hardware sem se preocupar com a parte do firmware do CLP. Outra vantagem desta ferramenta é que a mesma pode converter o diagrama Ladder na linguagem C ANSI, permitindo a portabilidade para outros sistemas microcontrolados.
Utilizando a ferramenta citada no trabalho de Westhues (2010), o trabalho apresentado no artigo de Rohde et al (2011) apresenta o desenvolvimento de hardware de um CLP de baixo custo que tem como componente principal um microcontrolador da família PIC da Microchip. Neste trabalho buscou-se apenas desenvolver a parte de periferia do CLP com saídas a relé e entradas optoacopladas permitindo seu uso em aplicações didáticas. A parte de software fica por conta da ferramenta LDMicro.
Em (DA COSTA, 2006), a proposta foi desenvolver um controlador programável para uso geral que utilize na sua arquitetura lógica programável estruturada (FPGA) e, macro instruções para programação desse controlador, que seria utilizado para aplicações de instrumentação. O objetivo da utilização de lógica programável nessa proposta é integrar em um único dispositivo as funções do microcontrolador e dos circuitos integrados de aplicações específicas (Application-specific integrated circuit - ASICs) e, estudar a possibilidade de minimizar a realização dos ciclos de busca das instruções, visando a melhoria das dimensões do sistema, o rendimento de operação do controlador e a redução do consumo de energia.
42
Esse trabalho deu origem também ao seu livro voltado para esta aplicação citado em da Costa (2006, 160 p.).
Em Chmiel (2011) é apresentado uma abordagem para a concepção e construção de CPUs para os controladores lógicos programáveis implementadas em uma plataforma de desenvolvimento de FPGA. As unidades apresentadas são otimizadas para o mínimo de resposta e rendimento de tempo. A estrutura de CPU é baseada na arquitetura de processamento de bits e palavras e dois tipos de métodos de controle de troca de dados: com handshaking - os dados de controle são passados através das duas unidades de flip-flop com reconhecimento, sem handshaking - os dados de controle são passados através da RAM de porta dupla. Uma terceira unidade - um simples processador – foi construída para comparar com os dois acima. O trabalho apresenta os resultados da execução, que mostram quantos recursos do circuito do FPGA são utilizados para implementar as unidades apresentadas.
4.3 Discussão
A partir desses trabalhos apresentados, buscou-se integrar dispositivos microcontrolados e dispositivos lógicos programáveis para implementação de controladores lógicos programáveis que permitam a expansão de periféricos de forma modular e configurável. A solução apresentará uma unidade de processamento baseada em um microcontrolador que se encarregará de executar as instruções de diagramas Ladder para programação de controle de processos industriais e um dispositivo lógico programável que se encarregará de gerenciar os elementos periféricos como interfaces de entradas e saídas digitais e PWMs que controlam os processos externos.
Como apresentado em artigos de alguns fabricantes de PLDs em geral, tais como, Atmel, Xilinx e Altera, uns dos usos desses dispositivos programáveis é a implementação de unidades de expansão de entradas e saídas para interfaceamento com outros dispositivos com eficiência e baixo custo (ATMEL, 2006) (XILINX, 2008) (ALTERA, 2011). Sendo assim, a parte da solução desenvolvida num PLD é um sistema de expansão de periféricos projetado de forma modular que
43
proporciona o crescimento da solução conforme a capacidade do dispositivo lógico programável e a sua aplicação.
Tendo em vista que para aplicações industriais de uma maneira geral, os CLPs de mercado são consagrados, a proposta permite o uso deste trabalho em prototipação e P&D na área de mecatrônica, usando uma abordagem aberta e de custo relativamente baixo, através da utilização de recursos de software gratuito e de código aberto e módulos microcontrolados e de lógica programável de baixo custo.
Além disso, como uma contribuição adicional, o estudo contribui para a utilização de PLDs como expansão de periféricos e, sobretudo a capacidade de reconfiguração de hardware, numa abordagem modular visando ao crescimento da solução através da adição de novos recursos periféricos conforme a capacidade do PLD e a sua aplicação.
No capítulo seguinte será apresentada a solução proposta através de dois estudos de caso que mostram a integração dessas duas tecnologias embarcadas para o desenvolvimento de CLPs.
5 SOLUÇÃO PROPOSTA
Como mostrado até o momento, o presente trabalho visa a desenvolver um CLP de plataforma aberta para controle de processos discretos utilizando lógica programável para expansão de periféricos.
Como solução proposta neste trabalho, será apresentada a integração de tecnologias embarcadas como sistemas microcontrolados, com poder de processamento suficiente para rodar sistemas operacionais abertos (tal como, distribuições Linux) e dispositivos lógicos programáveis (PLDs e FPGAs) para a expansão de periféricos, que possam ser programados ou reconfigurados conforme os requisitos da aplicação. Esta abordagem possibilita o desenvolvimento de controladores lógicos programáveis (CLPs) integrando duas tecnologias, uma para processamento de instruções (microcontrolador), e outra que gerenciará os elementos de periferia (PLDs), tais como: interfaces de entrada/saída digitais, PWMs, temporizadores, etc.
A proposta foi validada com dois estudos de caso: Um demonstrando o uso da linguagem Ladder, específica para programação da lógica de processos em CLPs, em um sistema microcontrolado controlando um processo simples e outro estudo de caso demonstrando o potencial de expansão e configuração de periféricos com o uso de dispositivo de lógica programável.
Como mostra o modelo geral da Figura 11, a proposta é composta por um sistema microcontrolado que se encarregará de processar as instruções de um programa portado da linguagem Ladder para a plataforma microcontrolada escolhida e um dispositivo lógico programável que gerenciará os elementos de periferia que controlará o processo final.
45
Controlador Lógico Programável
Sistema
microcontrolado
Dispositivo Lógico
Programável
PWMsTimers/
CountersE/S
Interface de comunicação
Aplicação
LADDER
Inte
rfa
ce
de
En
tra
da/
Sa
ída
Pro
ce
ss
o
Figura 11 – Modelo geral da proposta.
Nos estudos de casos apresentados adiante, buscou-se
validar os conceitos através de um experimento prático de controle de processos industriais. Tal que, no segundo estudo de caso fez-se a validação integrando todo o sistema em um processo de controle de um elevador industrial.
5.1 Estudo de caso 1 – Camada de abstração de hardware para interpretação de lógica Ladder
Nesse tópico será apresentado o uso da linguagem Ladder, específica para programação da lógica de processos em CLPs, rodando em uma plataforma de hardware baseada num microcontrolador ARM executando um sistema operacional de uso geral, livre e de código aberto. Para isso, algumas pesquisas foram realizadas com o intuito de achar uma ferramenta de programação Ladder que fosse independente de fabricantes de CLP e que permitisse a adaptação para outras plataformas programáveis. Com isso, foi encontrado uma ferramenta adequada a este objetivo, chamada LDMicro, desenvolvida pelo autor Jonathan Westhues e apresentada em WESTHUES (2010).
Sendo assim, neste estudo foi proposto o desenvolvimento da uma Camada de Abstração de Hardware (do inglês, Hardware Abstract Layer - HAL) para integrar as plataformas escolhidas
46
com as instruções geradas pela ferramenta do LDMicro. Com isso, foi possível adaptar um sistema microcontrolado, executando o ciclo de operação característico de um controlador lógico programável, para controle de um processo industrial. E, independente do HAL desenvolvido, a programação da lógica que controla o processo final pode ser então toda desenvolvida com a linguagem Ladder.
A seguir serão apresentados uma breve descrição da ferramenta LDMicro, das plataformas de desenvolvimento de hardware utilizadas, do HAL desenvolvido e o experimento validando o conceito.
5.1.1 Ferramenta LDMicro
Os CLPs são geralmente programados em linguagem Ladder. Isso por que os CLPs originalmente substituíram sistemas de controle baseados em lógica de relés, e quarenta anos depois, ainda se permanece utilizando esta linguagem. Um CLP, assim como um microprocessador, executa uma lista de instruções em sequencia. As ferramentas Ladder deixam isso transparente; é possível programar o CLP ligando os contatos de relés e bobinas na tela, e o interpretador Ladder irá simular o circuito que foi desenhado. Alguns contatos de relés podem ser ligados a sinais de entrada reais; Algumas das bobinas podem ser ligadas a saídas. Desta forma, é possível fazer a simulação do circuito e interagir com outros dispositivos, e até controlar coisas.
Os microcontroladores modernos de baixo custo passaram a ter o poder computacional de um CLP a partir de 1975. Eles passaram a processar mais MIPS para rodar uma lógica Ladder relativamente complexa com um ciclo de operação de alguns milissegundos. Um CLP normalmente tem uma espécie de programa do tipo "interpretador" ou "máquina virtual", mas se o interesse é realizar uma lógica simples em um processador sem muita memória então um compilador pode ser uma boa ideia. Sendo assim, o autor WESTHUES (2010) desenvolveu um compilador Ladder (denominado LDMicro), de código aberto e distribuição livre, que simula e gera código binário para uma lista
47
de microcontroladores de baixo custo das famílias PIC (Microchip) e AVR (ATMEL).
Esse compilador é capaz de trabalhar com os principais componentes disponível em um software de lógica Ladder de um CLP convencional. Nele é possível adicionar desde componentes simples como: contatos (sinais de entrada) e bobinas (sinais de saídas); até componentes mais complexos, tais como: temporizadores, PWM, contadores, operações aritméticas, entre outros.
Outra vantagem do LDMicro é que ele é capaz de gerar código em linguagem C ANSI da lógica Ladder, que pode ser usado para portar para qualquer outro microcontrolador. Na Figura 12 é apresentada a tela de programação do LDMicro.
Figura 12 – Tela de programação do LDMicro.
5.1.2 Plataformas de hardware
48
Neste estudo de caso foram utilizados duas plataformas de hardware para desenvolvimento do HAL comentado até o presente momento: o módulo ConnectCore 9P 9215 (DIGI, 2003) e a RaspBerry Pi (RaspBerry Pi Fundation, 2013). Essas duas plataformas são baseadas em um microcontrolador de arquitetura ARM e executam uma distribuição livre do sistema operacional Linux, portadas por cada um dos fabricantes para a sua plataforma.
A diferença entre essas duas plataformas é que o módulo ConnectCore foi projetado para aplicações robustas e comerciais e a RaspBerry Pi para uso acadêmico, portanto, o custo da primeira é muito maior. Entretanto, o módulo ConnectCore foi adquirido primeiro e utilizado neste estudo apenas pra validar o conceito do HAL, sendo que a continuação do trabalho no estudo de caso 2 foi feita somente na RaspBerry Pi, justamente por ela ser uma plataforma bem mais barata.
A seguir será apresentada uma descrição dessas plataformas.
5.1.2.1 ConnectCore 9P 9215
O módulo, denominado ConnectCore 9P 9215, é fabricado pela empresa americana Digi International
® e tem as seguintes
características (DIGI, 2003):
a) Processador RISC NS9215 de 32-bit NET+ARM (ARM926EJ-S) @ 150MHz;
b) Núcleo ARM9 com Unidade de Gerenciamento de Memória (MMU - Memory Management Unit);
c) Cache de dados de 4K/cache de instruções de 4K; d) 8MB SDRAM (pode suportar um máximo de 64MB
SDRAM); e) 4MB NOR Flash (pode suportar um máximo de 16MB
NOR flash); f) Dez temporizadores de propósito geral; ConnectCore 9P
9215 suporta sete como temporizadores/contadores e um decodificador de quadratura;
49
g) 64 pinos de General Purpose Input/Outputs (GPIOs) com até cinco funções diferentes multiplexadas (todos são ligados ao conector X2);
h) Dois conectores de 80 pinos; i) Até quatro UARTs; j) Um canal de Serial Peripheral Interface (SPI),
multiplexados em diferentes lugares; k) Ethernet 10/100Mbps MAC/PHY integrada; l) Interface I2C; m) Sinais JTAG acessível no conector do módulo; n) Oito entradas de Conversor Analógico-Digital (Analog to
Digital Converter - ADC); o) 2x flexible interface modules (FIMs) rodando no máx. a
300 MHz, integrado no processador NS9215; p) Dois LEDs (LE1: verde, e LE2: laranja) disponível no
modulo; q) 16 bits de dados e 17 bits de barramento de endereço,
ambos são buferizados; r) Alimentação de +3.3V.
A Figura 13 mostra a foto do módulo.
Figura 13 – Foto do módulo ConnectCore 9P 9215.
Neste módulo vem pré-instalado uma versão do Sistema
Operacional Linux para dispositivos embarcados baseado no
50
kernel 2.6, intitulado Digi Embedded Linux. O fabricante Digi®
também fornece uma Integrated Development Environment (IDE), chamada DigiEL
®, para desenvolvimento de aplicações
para esta platatorma. Além disso, a Digi International® fornece
suporte a drivers para os principais periféricos disponíveis no microcontrolador ARM9 do módulo, tais como: portas de GPIO, temporizadores, RTC, PWM, portas Seriais, SPI, I2C, waItchdog, USB, conversor A/D, entre outros.
A Digi® comercializa também um kit de desenvolvimento
baseado numa placa de periferia, incluindo os softwares acima e cabos diversos, para facilitar o desenvolvimento de aplicações para a sua plataforma. A Figura 14 mostra a foto da placa do kit de desenvolvimento da Digi
®.
Figura 14 – Foto da placa do kit de desenvolvimento da Digi.
5.1.2.2 RaspBerry Pi
51
Raspberry Pi é um computador de baixo custo do tamanho de um cartão de crédito, comumente chamado de Single Board Computer, desenvolvido no Reino Unido pela Fundação Raspberry Pi. Todo o hardware é integrado em uma única placa. O objetivo principal desta placa é de estimular o ensino de ciência da computação básica em escolas (RASPBERRY PI FUNDATION, 2013).
O computador é baseado em um system on a chip (SoC) Broadcom BCM2835, que inclui um processador ARM1176JZF-S de 700 MHz, GPU VideoCore IV,8 e 512 MB de memória RAM em sua última revisão. O projeto não inclui uma memória não volátil (como um disco rígido), mas possui uma entrada de cartão SD para armazenamento de dados.
Existem atualmente dois modelos: Modelo A e Modelo B. A grande diferença entre os dois modelos é que o Modelo B possui um controlador Ethernet e duas portas USB, enquanto que o Modelo A possui apenas uma porta USB e nenhuma porta de Ethernet. Apesar de não possuir a porta Ethernet, o Modelo A pode ser conectado a internet através de um adaptador USB de Ethernet ou Wi-Fi. A seguir é apresentado as principais características do modelo B da Raspberry Pi:
a) Processador de 700 MHz ARM1176JZF-S core (família
ARM11); b) Unidade de processamento gráfico (GPU) deoCore IV,
OpenGL ES 2.0, 1080p30 h.264/MPEG-4 AVC high-profile decoder;
c) Memoria RAM de 512MB; d) Uma saída HDMI (digital audio/video output); e) Duas portas USB 2.0; f) Uma interface para cartão SD/MMC/SDIO; g) Uma interface 10/100 Ethernet RJ45; h) Uma saída de vídeo composto RCA; i) Uma saída analógica de áudio padrão Jack de 3,5 mm; j) 8 pino de GPIOs; k) 3 interfaces seriais: UART, I2C e SPI; l) Dimensões: 85.6 x 53.98 x 17mm.
O Raspberry Pi é compatível com sistemas operacionais
baseados em Linux. O Raspbian é a distribuição linux oficial do
52
Raspberry Pi. As distribuições Arch Linux e Debian são também oficialmente suportadas e disponíveis para download. O sistema operacional é normalmente armazenado no cartão SD.
Qualquer linguagem que possa ser compilada na arquitetura ARMv6 pode ser usada para o desenvolvimento de software. O projeto tem como objetivo usar Python como linguagem de referência com suporte à BBC_BASIC
1.
Apesar de que a Raspberry Pi tenha sido criada com o intuito de ser uma ferramenta de aprendizado inicial para ensino de lógica de programação, o seu custo e usabilidade tem despertado muito interesse no mundo acadêmico para seu uso no desenvolvimento de trabalhos de P&D nas diversas áreas afins. A Figura 15 mostra a foto da placa da Raspberry Pi modelo B.
Figura 15 – Foto da placa da Raspberry Pi modelo B.
1 “O BBC BASIC foi desenvolvido por Roger Wilson em 1981 como
linguagem de programação nativa para o computador doméstico BBC Micro, com microprocessador MOS Technology 6502. Era uma versão do BASIC adaptado para o projeto de ensino informatizado britânico idealizado pela BBC” (Wiki, 2013).
53
5.1.3 Porte do LDMicro para as plataformas
Como discutido no item 5.1.1, o LDMicro é capaz de gerar código em linguagem C ANSI da lógica Ladder, que pode ser portado para qualquer outro microcontrolador. Desta forma, foi utilizado este recurso para criar um porte deste software para o módulo microcontrolado da Digi
® e para a RaspBerry Pi, criando
a camada de abstração de hardware. De forma a exemplificar a elaboração do porte do LDMicro
para essas plataformas, é mostrado na Figura 16 um simples exemplo de código em linguagem Ladder, com apenas duas linhas de código, em que se tem um contato de entrada (XA0 - que representará um pino de entrada do CLP) e uma bobina de saída (YB0 - que representará um pino de saída do CLP). O programa mostrado na figura executa um processo de ativar a bobina YB0 quando o contato XA0 for ativado e desativa a YB0 quando XA0 for desativado.
Figura 16 – Exemplo de código em linguagem Ladder.
54
A partir do programa em Ladder, o LDMicro gera um código em linguagem C ANSI conforme a Figura 17. Esse código apresenta uma função principal, chamada void PlcCycle(void), que executa todo o processo da lógica Ladder elaborada no LDMicro (linhas 27 a 49). Para o contato XA0 e a bobina YB0 represente, respectivamente, um pino de entrada e um pino de saída do CLP, o código da Figura 17 permite a prototipação externa das funções de leitura e escrita de portas de Entrada/Saída, conforme apresentado nas linhas 22 e 25. A partir disso, as funções que irão controlar as Entradas/Saídas do CLP podem ser prototipadas em um arquivo de cabeçalho externo Ladder.h, que já é incluso no código gerado pelo LDMicro (linha 1), e o código específico para controle de periféricos de cada plataforma de hardware pode ser escrito em outros arquivos .C.
55
Figura 17 – Código gerado automaticamente pelo LDMicro.
56
Simplificando o processo de elaboração da camada de abstração de hardware para as plataformas escolhidas, foi criado arquivos .C que contém as funções de controle dos principais periféricos do microcontrolador, e as mesmas foram prototipadas num arquivo Ladder.H para serem usadas em conjunto com o arquivo de código gerado pelo LDMicro. Com isso, não é necessário fazer qualquer modificação no código da ferramenta de programação Ladder. Basta apenas adicioná-lo ao projeto do CLP da plataforma específica e compilá-la. O arquivo binário (executável) gerado pode, então, ser portado para a plataforma para executar a lógica Ladder programada. A Figura 18 mostra o conjunto dos principais arquivos que fazem parte do HAL.
PROJETO CLP
Ladder.HLDmicro.C
Main.C
Ladder.C
Arquivo
gerado pelo
Ldmicro que
contém a
função
PlcCycle()
Arquivo que contém a
prototipação das funções de
controle de periféricos da
plataforma específica Arquivo que
contém a
definição das
funções de
cotronle de
periféricos da
plataforma
específica
Arquivo que
contém a função
principal main(),
ao qual chama a
função
PlcCycle()
Código binário
Figura 18 – Conjunto dos principais arquivos que fazem parte do
HAL da plataforma.
57
5.1.4 Validação
Para validação do HAL foi desenvolvido uma aplicação em Ladder no LDMicro para controlar um protótipo de uma célula de manufatura de envasamento de garrafas. Para isso, foi utilizado a placa do kit de desenvolvimento da Digi
® para controlar o
protótipo com a lógica Ladder rodando no módulo ConnectCore 9P 9215.
O protótipo consiste de uma esteira rolante que conduz a garrafa vazia do ponto de admissão da garrafa (início do processo), posicionamento da garrafa sob a válvula injetora de bebida (representado por sensores), temporização/ou detecção do nível de líquido armazenado na garrafa, encaminhamento da garrafa cheia para uma caixa de armazenamento (representado por sensores), detecção e contabilização das garrafas armazenadas na caixa e alarme de caixa cheia para despacho manual pelo operador. Para isso, foi montada uma estrutura física para emular o processo de envasamento de garrafas. A Figura 19 apresenta o aparato físico usado nos testes em laboratório.
Figura 19 – Aparato físico usado nos testes em laboratório.
58
Este experimento serviu como base para validação da usabilidade do LDMicro como ferramenta de programação em linguagem Ladder para controle discreto em uma plataforma microcontrolada que não tem suporte direto por esta ferramenta.
O HAL desenvolvido em linguagem C para executar a função PLCCycle() (que contém a lógica Ladder do processo executado na célula de manufatura de envasamento de garrafas) no módulo ConnectCore 9P 9215 foi elaborado de forma estruturada em arquivos que contém as funções de controle das interfaces mapeadas do CLP e as funções específicas de controle dos periféricos da plataforma para que este HAL possa ser facilmente adaptado para outra plataforma, apenas alterando o escopo das funções de escrita e leitura dos periféricos. Desta forma, este HAL foi facilmente adaptado para a Raspberry Pi que é a plataforma de baixo custo escolhida para a continuação deste trabalho no próximo estudo de caso. No Apêndice B é apresentado um tutorial que mostra como utilizar o HAL usando como exemplo o experimento do estudo de caso 2.
5.2 Estudo de caso 2 – Integração do dispositivo microcontrolado e o dispositivo lógico programável
Neste estudo de caso buscou-se integrar as duas tecnologias de sistemas embarcados, um dispositivo microcontrolado e um dispositivo lógico programável, para se comportarem como um controlador lógico programável. O sistema microcontrolado se encarregará de processar as instruções de um programa portado da linguagem Ladder (conforme apresentado no estudo de caso 1), ou seja, ele será a CPU e a memória do CLP. E o PLD gerenciará os elementos de periferia que controlará o processo externo.
Para desenvolvimento deste estudo de caso, foi utilizado o hardware da Raspberry Pi (como apresentado no primeiro estudo de caso) e um kit didático de lógica programável baseada na família mais atual de CPLDs da ALTERA, a MAXV.
O modelo do CPLD, o 5M570ZT100XXX, é um componente intermediário da família MAXV. Este possui 570 elementos lógicos, equivalente a 440 macrocélulas, disponível no
59
encapsulamento TQFP de 100 pinos, possuindo quatro Global Clocks, um oscilador interno e 79 pinos de entradas/saídas.
O kit didático baseado neste CPLD foi escolhido por fazer parte do projeto “FPGA para Todos”
2, ao qual o autor deste
trabalho é pesquisador e participou ativamente no desenvolvimento deste kit (Figura 20).
Figura 20 – Kit didático de CPLD MAXV.
Como mostrado na Figura 21, a integração da Raspberry
Pi com o kit didático de CPLD se deu através da interface de comunicação da Serial Peripheral Interface (SPI). A escolha por esta interface se deve pela sua popularidade e também por estar presente na maioria dos microcontrolodores. Além disso, em comparação a outras interfaces também populares com o mesmo objetivo de interligar periféricos ou dispositivos dentro de uma plataforma embarcada como, por exemplo, a interface Inter-Integreted Circuit (I
2C) ou a interface 1-Wire,.a SPI é capaz de
alcançar velocidades muito superiores pois a mesma possui dois canais dedicados para a troca de dados, enquanto que nas outras citadas só possuem um.
2 O “FPGA para Todos” é um projeto coordenado pelo professor Édson Mélo
do campus Florianópolis do IF-SC, que visa desenvolver uma plataforma integrada de soluções para o ensino de lógica programável, incluindo veículos de disseminação diversificados.
60
O HAL desenvolvido no estudo de caso 1 controla os blocos de periféricos programados no CPLD através desta interface por um protocolo desenvolvido especificamente para esta aplicação.
Controlador Lógico Programável
Kit didático CPLD
MAXV
PWMsTimers/
CountersE/S
Aplicação
LADDER/LDMICRO
En
tra
da
s
Pro
ce
ss
o
Raspberry Pi
MOSIMISO
SCLKSS
Interface
SPI
Sa
ída
s
16
16
Figura 21 – Integração da Raspberry Pi com o kit de CPLD.
5.2.1 Implementação da programação do CPLD
Para implementação da programação de um PLD em geral é necessário uma ferramenta EDA de apoio ao projeto e uma linguagem de alto nível para descrever o hardware a ser implementado no dispositivo.
Para este estudo, foi utilizada a ferramenta EDA da ALTERA, o Quartus II, por se tratar de um CPLD fabricado pela mesma empresa. Esta ferramenta permite analisar e sintetizar projetos de linguagem de descrição de hardware (Hardware Description Language - HDL), permitindo que o desenvolvedor possa compilar seus projetos, realizar análise de tempo, examinar diagramas de Register Transfer Level (RTL), simular a reação de um projeto a diferentes estímulos, e configurar o dispositivo de destino com o programador. Ela permite desenvolver projetos nas linguagens Verilog HDL e VHDL (Very High Speed Integrated Circuit Hardware Description Language),
61
esta última utilizada para implementar a programação deste estudo.
A estrutura de hardware do CPLD consiste de três blocos principais (Figura 22): o bloco SPI, o bloco de controle e o bloco de periféricos. Este último bloco integra módulos de PWM, temporizadores/contadores e interfaces de Entrada/Saída. Esses módulos são endereçados e comandados através de um barramento de Comando/Endereço de 8 bits e um barramento de dados de 16 bits pelo bloco de controle.
O bloco de controle foi projetado de forma que o projeto possa ser expansível conforme a capacidade do PLD e da aplicação exigida no processo externo.
Dispositivo Lógico Programável
Bloco de
periféricos
Bloco de
controle
PWM0
PWM1
PWM2
Temporizador/
Contador
Interface de
Entradas digitais
Interface de
Saídas digitais
...
Bloco SPI
Comando/
EndereçoDados
8
16
8
Figura 22 – Estrutura de hardware do CPLD.
5.2.2 Protocolo de comunicação
Antes de descrever os blocos da estrutura de hardware desenvolvida no CPLD, é necessário descrever o protocolo de comunicação, desenvolvido pelo grupo “FPGA para Todos”, usado para configurar os blocos periféricos da solução (Figura
62
23). Este protocolo baseia-se no principio de requisição e resposta para executar uma operação. O CPLD sempre dependerá de uma requisição a ele para executar uma operação. Os dados de resposta vão depender do tipo de operação. A palavra de requisição sempre será composta por 4 bytes, sendo eles, representado pelos bytes comando/endereço, dadoLo, dadoHi e checksum, como mostra a Figura 23. A palavra de resposta também conterá 4 bytes, entretanto o primeiro byte é um valor desconsiderado pelo protocolo e os outros bytes são o dadoLo, dadoHi e checksum, respectivamente.
Byte 1
Dado
desconsiderado
pelo protocolo
Byte 1
comando/
endereço
Byte 2
dado_Lo
Byte 4
checksum
Byte 2
dado_Lo
Byte 3
Dado_Hi
Requisição
Byte 3
Dado_Hi
Resposta
Byte 4
checksum
Figura 23 – Protocolo de comunicação.
O primeiro byte, o comando/endereço, definirá a operação
a ser executada e o endereço do módulo periférico a ser acessado nesta operação. Este byte é dividido da seguinte forma:
a) Comando: é representado pelos três bits mais
significativos do byte comando/endereço. Portanto, é possível ter até sete operações mapeadas na solução. Entretanto, neste estudo foram mapeadas apenas as operações descritas na Tabela 2:
63
Tabela 2 – Operações mapeadas na solução.
Comando
(3 bits mais significativos de comando/endereço)
Operação Descrição
001xxxxxb Leitura
Executa uma operação de leitura. Utilizado para ler o registrador de dados do módulo da interface de entradas digital.
110xxxxxb Escrita
Executa uma operação de escrita simples. Utilizado para configurar os módulos de PWMs e Temporizadores e para escrever no registrador de dados do módulo da interface de saídas digitais.
101xxxxxb Escrita OR
Executa uma operação de escrita lógica OU. Utilizado para executar uma lógica OU entre os dados enviados pelo protocolo (dado_Hi e dado_Lo) e os dados já contidos no registrador de dados do módulo da interface de saídas digital.
111xxxxxb Escrita AND
Executa uma operação de escrita lógica E. Utilizado para executar uma lógica E entre os dados enviados pelo protocolo (dado_Hi e dado_Lo) e os dados já contidos no registrador de dados do bloco da interface de saídas digital.
100xxxxxb Escrita XOR
Executa uma operação de escrita lógica OU Exclusivo. Utilizado para executar uma lógica OU-Exclusivo entre os dados enviados pelo protocolo (dado_Hi e dado_Lo) e os dados já contidos no registrador de dados do bloco da interface de saídas digital.
b) Endereço: é representado pelos cinco bits menos
significativos do byte comando/endereço. Portanto, é possível ter até 32 módulos de periféricos mapeados na
64
solução, em cada direção (32 de entrada e 32 de saída). Entretanto, neste estudo foram mapeados apenas os blocos descritos na Tabela 3:
Tabela 3 – Blocos de periféricos mapeados na solução.
Endereço
(5 bits menos significativos de comando/endereço)
Bloco periféricos
xxx00000b Interface de entradas digitais
xxx00000b Interface de saídas digitais
Xxx11100b PWM0
Xxx11101b PWM1
Xxx11110b PWM2
A palavra de resposta a uma requisição feita da Raspberry
Pi para o CPLD vai depender do tipo de operação de comando a ser realizada. Numa requisição para uma operação de escrita em algum módulo de periféricos a palavra deve conter dados significativos em todos os bytes. A resposta enviada para a Raspberry Pi, neste caso, irá conter sempre três bytes com dados fixos (que poderão ser desconsiderados pela Raspberry Pi) e o checksum de resposta. O checksum da requisição e da resposta numa operação de escrita é calculado em cima dos bytes comando/endereço, dado_Lo e dado_Hi da requisição, tanto no lado do CPLD quanto do lado da Raspberry Pi. Os dois checksum são comparados nos dois dispositivos para validar a integridade dos dados trocados no protocolo. A Figura 24 apresenta a característica dos dados trocados no protocolo numa operação de escrita.
65
Byte 1
Dado desconsiderado
pelo protocolo
(0x33)
Byte 1
comando/endereço
(Comando ESCRITA e
endereço do periférico)
Byte 2
dado_Lo
(Valor a ser escrito)
Byte 4
checksum
Byte 2
dado_Lo
(0xAA)
Byte 3
dado_Hi
(0x55)
Requisição
Byte 3
Dado_Hi
(Valor a ser escrito)
Resposta
Byte 4
checksum
Figura 24 – Característica dos dados trocados no protocolo numa
operação de escrita.
Numa requisição para uma operação de leitura a palavra
enviada da Raspberry Pi para o CPLD conterá o byte comando/endereço, os bytes dado_Lo e dado_Hi (podendo conter quaisquer valores) e o checksum da requisição calculado em cima desses três primeiros bytes. A resposta enviada para a Raspberry Pi conterá o byte com valor a ser desconsiderado, os bytes dado_Lo e dado_Hi com os valores lidos do registrador de dados do periférico de entrada endereçado e o checksum da resposta, respectivamente. Este checksum, numa operação de leitura, é calculado em cima do byte comando/endereço da requisição junto com os bytes dado_Lo e dado_Hi da resposta. Para validar a integridade dos dados recebidos pela Raspberry Pi, deve-se calcular o checksum com os dados da palavra de resposta e compará-lo com o checksum do mesmo. A Figura 25 apresenta a característica dos dados trocados no protocolo numa operação de leitura.
66
Byte 1
Dado desconsiderado
pelo protocolo
(0x33)
Byte 1
comando/endereço
(comando LEITURA e
endereço do periférico)
Byte 2
dado_Lo
(valor qualquer)
Byte 4
checksum
Byte 2
dado_Lo
(valor lido)
Byte 3
dado_Hi
(valor lido)
Requisição
Byte 3
Dado_Hi
(valor qualquer)
Resposta
Byte 4
checksum
Figura 25 – Característica dos dados trocados no protocolo numa
operação de leitura.
5.2.3 Bloco SPI
O bloco SPI implementa, no CPLD, a interface SPI entre a Raspberry Pi e o bloco de controle. Esta interface é uma forma de comunicação presente internamente na maioria dos microcontroladores atuais. Pode operar com um dispositivo mestre único e com um ou mais dispositivos escravos. Os dados são obtidos a partir da combinação dos sinais chamados “SCLK” ou CLOCK e “MOSI” (para envio) e “MISO” (para recebimento) gerando o sinal de “DADO” ilustrado na Figura 26. Nesse modo de operação por exemplo, no momento da transição positiva (borda de subida) do sinal “SCLK”, o sinal “MOSI” ou “MISO” deve ser enviado ou lido gerando a informação presente em “DADO”. A comunicação é chamada de síncrona, significando que o sinal de clock é enviado ao dispositivo receptor juntamente com o sinal de dados. O mecanismo gerador do sinal de “SCLK” gera também o sinal “MOSI” garantindo a perfeito sincronismo e transmissão é bem sucedida mesmo com grandes variações na frequência ou atrasos no sinal de “clock”.
67
1 0 1
1 0 1
SCLK
MISO
MOSIOU
DADO
Figura 26 – Envio e recebimento de sinais SPI.
O bloco SPI desenvolvido para essa aplicação foi
elaborado para operar em modo escravo, e possui algumas características específicas para a comunicação com o bloco de controle, conforme mostra a Figura 27. Dois registradores de 8 bits foram implementados neste bloco para armazenar os dados recebidos do bloco de controle e para armazenar os dados a serem enviados pela comunicação SPI. O registrador chamado de “SAÍDA” recebe o dado da interface SPI e envia para o bloco de controle. O registrador chamado de “ENTRADA” recebe o dado processado pelo bloco de controle pra ser devolvido pela interface SPI. A cada dado de 8 bits, um sinal de controle chamado “FIM_TRANSF” indica para o bloco de controle que uma transferência foi realizada. Por sua vez, o bloco SPI recebe um sinal do bloco de controle indicando que o dado recebido por ele foi processado (sinal “OK”). Um sinal independente, chamado “MODO_LOOPBACK” foi criado pra testar a funcionalidade do bloco SPI. Quando ele está ativo os dados recebidos do mestre pelo MOSI são ecoados na próxima transferência de dados.
68
Bloco
SPIMODO
LOOPBACK
MISOMOSISCLKSS
ENTRADA[7..0]
SAÍDA[7..0]
FIM_TRANSF
OK
8
8
Figura 27 – Bloco SPI.
5.2.4 Bloco de controle
Este bloco é responsável por processar os dados vindos do bloco SPI e direcioná-los para os barramentos de comando/endereço e de dados. É nele também que é verificado o checksum da palavra de requisição e é computado o checksum da palavra de resposta (Figura 28). O bloco de controle possui um registrador de entrada de 8 bits (ENTRADA_SPI) e um registrador de saída de 8 bits (SAÍDA_SPI) para armazenar e enviar os dados trocados com o bloco SPI. Os sinais “FIM_TRANSF_SPI” e “OK_SPI” servem sincronizar os dados com o bloco SPI, como explicado na seção anterior.
Após o processamento dos dados, quatro registradores armazenam os dados a serem trocados entre os barramentos da solução: “CMD_BUS” e “END_BUS” são os registradores que juntos correspondem ao dado do barramento de Comando/Endereço; “E_D_BUS” e “S_D_BUS” são os registradores de entrada e de saída responsáveis pela troca de dados com o barramento de dados.
Este bloco possui ainda um sinal “Clock” para entrada do clock do sistema e um sinal “ResetN” para reiniciar a lógica do bloco se algum erro ocorrer na comunicação.
69
8
8
Bloco de
Controle
ResetNClock
ENTRADA_SPI[7..0]
SAÍDA_SPI[7..0]
FIM_TRANSF_SPI
OK_SPI
E_D_BUS[15..0]
16
8
S_D_BUS[15..0]
CMD_BUS[7..5]END_BUS[4..0]
Figura 28 – Bloco de controle.
A lógica do bloco de controle foi projetada como uma máquina de estados finitos, representada na Erro! Fonte de referência não encontrada.. Na Tabela 4 é descrito o comportamento dessa máquina de estados.
Tabela 4 – Comportamento da máquina de estados do bloco de
controle.
Estados Descrição
Partida Estado inicial da máquina. Salta, no próximo ciclo de clock, para o próximo estado “Espera1”.
Espera1 Aguarda o sinal “Fim_transf” do bloco SPI, que indica a chegada ao registrador “Entrada SPI” do primeiro byte da requisição (referente ao byte “comando_endereço”).Quando isto ocorre, transita para o próximo estado “Proc_CMD”. O dado disponível no registrador “Saída_SPI” neste estado, referente ao primeiro byte da palavra de resposta do protocolo, é o valor fixo “0x33”.
Proc_CMD Estado responsável por armazenar o byte “comando_endereço”, disponível no registrador “Entrada SPI”, e, processá-lo, conforme a operação descrita nele. Se a operação for de leitura, o dado é habilitado nos registradores “CMD_BUS” e “END_BUS” para estarem disponíveis no barramento Comando/Endereço. O dado a ser lido do barramento de dados já estará disponível no registrador “E_D_BUS”. Se a operação for de escrita, o dado é apenas armazenado internamente para ser habilitado num próximo estado, pois é necessário que todos os bytes do protocolo estejam disponíveis no bloco de controle. O sinal “OK” é fornecido nesse estado para indicar ao bloco SPI que o dado foi processado.
70
O estado seguinte da máquina é o “Espera2”.
Estados Descrição
Espera2 Aguarda o sinal “Fim_transf” do bloco SPI, indicando a chegada ao registrador “Entrada SPI” do segundo byte da requisição referente ao dado “dado_Lo”. Quando isto ocorre, pula para o estado “Dado1”. O dado disponível no registrador “Saída_SPI” neste estado, referente ao segundo byte da palavra de resposta do protocolo, é definido pelo tipo de operação fornecido no primeiro byte da requisição: se for de leitura, o dado menos significativo do registrador “E_D_BUS” estará disponível nele. Se for de escrita, o seu valor será “0xAA”.
Dado1 Estado responsável por armazenar o segundo byte “dado_Lo”, disponível no registrador “Entrada SPI”, e, processá-lo conforme a operação fornecida no primeiro byte da requisição. Se a operação for de leitura, o dado é apenas armazenado internamente para ser utilizado no cálculo de verificação do checksum da palavra de requisição do protocolo quando todos os bytes forem recebidos. Se a operação for de escrita, o dado é apenas armazenado internamente para ser habilitado num próximo estado, pois é necessário que todos os bytes da palavra de requisição do protocolo estejam disponíveis no bloco de controle. O sinal “OK” é fornecido para indicar ao bloco SPI que o dado foi processado. Pula para o próximo estado “Espera3”.
Espera3 Aguarda o sinal “Fim_transf” do bloco SPI, indicando a chegada ao registrador “Entrada SPI” do terceiro byte da requisição referente ao dado “dado_Hi”. Se isto ocorre, pula para o próximo estado “Dado2”. O dado disponível no registrador “Saída_SPI” neste estado, referente ao terceiro byte da palavra de resposta do protocolo, é definido pelo tipo de operação fornecido no primeiro byte da requisição: se for de leitura, o dado mais significativo do registrador “E_D_BUS” estará disponível nele. Se for de escrita, o seu valor será “0x55”.
Dado2 Estado responsável por armazenar o terceiro byte “dado_Hi”, disponível no registrador “Entrada SPI”, e, processá-lo conforme a operação fornecida no primeiro byte da requisição. Se a operação for de leitura, o dado é apenas armazenado internamente para ser utilizado no cálculo de verificação do checksum da palavra de requisição do protocolo quando todos os bytes forem recebidos. Se a operação for de escrita, o dado é apenas armazenado internamente para ser habilitado num próximo estado, pois é necessário que todos os bytes da palavra de requisição do
71
protocolo estejam disponíveis no bloco de controle. O sinal “OK” é fornecido para indicar ao bloco SPI que o dado foi processado. Pula para o próximo estado “Espera4”.
Estados Descrição
Espera4 Aguarda o sinal “Fim_transf” do bloco SPI, indicando a chegada ao registrador “Entrada SPI” do quarto e último byte da requisição referente ao dado “checksum”. Se isto ocorre, pula para o próximo estado “Verif_CMD”. O dado disponível no registrador “Saída_SPI” neste estado é o checksum, referente ao quarto e último byte da palavra de resposta do protocolo. Este checksum é definido pelo tipo de operação fornecido no primeiro byte da requisição: se for de leitura, o checksum é calculado em cima do byte “comando/endereço” da palavra de requisição junto com os bytes “dado_Lo” e “dado_Hi” da palavra de resposta. Se for de escrita, o checksum é calculado em cima dos bytes “comando/endereço”, “dado_Lo” e “dado_Hi” da palavra de requisição.
Verif_CMD Este estado verifica se o checksum recebido é válido. Se for válido, é testado novamente o tipo a operação fornecido no primeiro byte da palavra de requisição. Se for de leitura, pula para o estado “Espera1”, pois esta operação já foi processada nos estados anteriores. Se for de escrita, pula para o estado “Proc_Esc”. Se o checksum é inválido, pula para o estado “Erro_CMD”.
Proc_Esc Este estado processa a operação de escrita conforme os bytes recebidos no protocolo. O byte “comando/endereço” é habilitado nos registradores “CMD_BUS” e “END_BUS” para estarem disponíveis no barramento Comando/Endereço e os bytes “dado_Lo” e “dado_Hi” são habilitados no registrador “S_D_BUS” para estarem disponíveis no barramento de dados.
Erro_CMD Aguarda um sinal do “Reset” para reiniciar a máquina. Um erro poderá ser verificado pelo dispositivo mestre (Raspberry Pi) testando o checksum da resposta, já que a máquina estando neste estado manterá no registrador “Saída SPI” o dado fixo “0x33” constantemente.
72
Máquina de Estados do bloco de controle
PARTIDA ESPERA1
PROC
CMD
ESPERA2
DADO1
ESPERA3
DADO2
ESPERA4
VERIF
CMD
PROC
ESC
ERRO
CMD
Fim_transf
Fim_transf
Fim_transf
Fim_transf
Fim_transf
Fim_transf
Fim_transf
Fim_transf
CMD = Escrita
CMD = Leitura
Reset
Reset
Reset
Checksum válido
Checksum válido
Checksum
inválido
Figura 29 – Máquina de estados do Bloco de controle.
5.2.5 Bloco de periféricos
O bloco de periféricos é composto por módulos que comandam e controlam os processos externos a serem automatizados pelo CLP. Como dito anteriormente, bloco de controle foi projetado de forma que o CLP possa ser expansível conforme a capacidade do PLD e da aplicação exigida no processo externo. Podem ser endereçados até 32 módulos periféricos no projeto. Entretanto, como este estudo não visa construir um CLP completo e sim apresentar a integração de dispositivos microcontrolados e de lógica programável foi dado ênfase apenas nos principais módulos de CLPs. Tais módulos referem-se as interfaces de entradas e de saídas digitais de 16bits cada uma. Foram adicionados também módulos de PWMs, utilizados para modulação de sinais digitais. Outros módulos também podem acionados como módulos específicos para controle de motores de passo, módulos de temporizadores
73
e contadores externos, módulos de controle Proporcional-Integral-Derivativo PID, entre outros.
Esses módulos são endereçados e comandados através de um barramento de Comando/Endereço de 8 bits e um barramento de dados de 16 bits pelo bloco de controle. Eles possuem basicamente registradores que recebem o byte comando/endereço que habilitam a operação e periférico endereçado e registradores de escrita ou leitura que configuram (no caso dos módulos PWMs) ou leem e escrevem os estados dos sinais de entrada e saída. A Tabela 5 apresenta a descrição dos módulos periféricos mapeados na solução com relação aos dados recebidos.
Tabela 5 – Descrição dos módulos periféricos mapeados na
solução com relação aos dados recebidos.
Módulo Operação suportada
Byte comando/endereço
Byte Dado_Lo
Byte Dado_Hi
Interface de entradas digitais
Leitura 00100000b Representa o byte menos significativo dos sinais de entrada
Representa o byte mais significativo dos sinais de entrada
Interface de saídas digitais
Escrita Escrita AND Escrita OR Escrita XOR
11000000b
11100000b
10100000b
10000000b
Representa o byte menos significativo dos sinais de saída
Representa o byte mais significativo dos sinais de saída
PWM0 Escrita simples
11011100b Representa o preescaler, período do sinal do PWM
Representa o duty cycle, largura de pulso do PWM
PWM1 Escrita simples
11011101b Representa o preescaler, período do sinal do PWM
Representa o duty cycle, largura de pulso do PWM
PWM2 Escrita simples
11011110b Representa o preescaler, período do sinal do PWM
Representa o duty cycle, largura de pulso do PWM
74
5.2.6 Validação
Para validação da integração das tecnologias de sistemas embarcados apresentados neste estudo de caso, buscou-se verificar o funcionamento e o comportamento do controlador lógico programável através de um experimento prático utilizando um protótipo de um elevador industrial de cinco andares. O experimento consiste na execução da lógica de controle do processo, desenvolvido em um diagrama Ladder, comandado pelo CLP apresentado neste estudo. O diagrama Ladder é convertido para um código em linguagem C e compilado para a Raspberry Pi juntamente com a camada de abstração de hardware desenvolvida para esta plataforma, que comanda os blocos de periféricos desenvolvidos no dispositivo lógico programável que, por fim, controla o elevador através de sensores, botões e motor, conforme mostra o modelo de montagem do experimento na Figura 30.
Controlador Lógico Programável
Kit didático CPLD
MAXV
PWMsTimers/
CountersE/S
Lógica LADDER
Elevador industrial
En
tra
da
s
Raspberry Pi
MOSIMISO
SCLKSS
Interface
SPI
Sa
ída
s
10
2
5 sensores
5 botões
2 atuadores
(mover motor)
Figura 30 – Modelo de montagem do experimento.
5.2.6.1 Estrutura do elevador
O protótipo do elevador é composto de uma estrutura metálica onde estão anexados os botões, sensores, motor e
75
cabine, como mostra a Figura 31. Existem cinco botões de chamadas de andares e cinco sensores que indicam a chegada da cabine nos andares. O motor de corrente contínua é fixado na parte superior da estrutura. Este motor possui seu eixo preso a uma haste cilíndrica com sulcos em espiral ao longo da sua face externa, formando uma rosca. Nesta haste está fixada a cabine do elevador e, conforme o sentido de giro do motor, a cabine é movida para cima ou para baixo ao longo desta haste. No limite inferior e superior da estrutura estão acoplados sensores de fim de curso, um em cada ponta, que estão ligados em paralelo ao botão de emergência, conectados diretamente na entrada de alimentação da fonte, servindo de proteção fazendo o desligamento do sistema quando for necessário.
Botões para
chamada dos
andares
Sensores de
chegada em
andares
Sensores de
limite
Cabine do
elevador
Motor
Botão de
emergência
Figura 31 – Protótipo do elevador industrial.
Este protótipo foi desenvolvido pelo professor pelo
professor Édson Mélo do campus Florianópolis do IF-SC, para
76
utilização em suas disciplinas envolvendo programação e projetos com microcontroladores e dispositivos lógicos programáveis.
5.2.6.2 Estrutura do CLP
A estrutura do CLP foi montada interligando a Raspberry Pi e o kit de CPLD MAXV através de uma placa de adaptação para matriz de contato do conector de GPIOs da Rasperry Pi, como mostra a Figura 32. As interfaces de entradas e saídas digitais foram programadas nos pinos de GPIOs do CPLD MAXV. Os sinais de controle (tal como o sinal de reset do CPLD) e da interface SPI foram programados nos pinos indicado na figura.
Interface de
entradas digitais
de 16 bits
Interface de
saídas digitais de
16 bits
Kit didático de
CPLD MAXV
Adaptador de
GPIOs para a
Raspberry Pi
Raspberry Pi
Interface SPI e
sinais de controle
Figura 32 – Estrutura do CLP.
Como dito anteriormente, este trabalho não visa a
desenvolver o CLP propriamente dito, mas sim mostrar através
77
de estudos de caso a integração desses dois dispositivos embarcados aplicando num experimento prático de um processo industrial para validar o conceito. Portanto, a eletrônica para condicionamento dos sinais de entrada e saída não foram contemplados nesse estudo.
5.2.6.3 Lógica Ladder, ciclo de operação e execução do programa
O diagrama Ladder que executa a lógica de controle do elevador industrial foi elaborado numa máquina de estados finitos. A lógica desta maquina de estados é mostrada resumidamente na Figura 33. Ela possui cinco estados principais apresentado na Tabela 6 do comportamento da máquina de estados do elevador industrial.
Tabela 6 – comportamento da máquina de estados do elevador
industrial.
Estados Descrição
Partida Estado inicial da máquina. Salta para o próximo estado “Posiciona”.
Posiciona Posiciona a cabine do elevador até chegar ao sensor que representada o 1º andar. Se chegar a esse andar, salta
para o próximo estado “Parado”.
Parado Aguarda até que um andar seja solicitado. Se andar solicitado for acima, salta para estado “Subida”. Se for
abaixo, salta para estado “Descida”.
Subida Posiciona a cabine do elevador até chegar ao andar solicitado. Chegou-se, salta para o estado “Parado”.
Descida Posiciona a cabine do elevador até chegar ao andar solicitado. Chegou-se, salta para o estado “Parado”.
78
Máquina de Estados do elevador industrial
Partida Posiciona
Parado
Subida
Descida
Início
Posiciona até
o 1º andar
1º andar
Aguarda
chamada
Chamada
andar abaixo
Chamada
andar acima
Chegou andar
solicitado
Chegou andar
solicitado
Aguarda
chegada no
andar solicitado
Aguarda
chegada no
andar solicitado
Figura 33 – Máquina de estados do controle do elevador.
O diagrama Ladder criado a partir desta máquina de
estados está apresentado no Apêndice A no final deste trabalho. Este diagrama foi todo desenvolvido no software LDMicro. Nele foi gerado o código equivalente em linguagem C ANSI e portado para a plataforma do CLP através da camada de abstração desenvolvida no estudo de caso 1 e adaptada para a Raspberry Pi ler e escrever nos blocos periféricos do PLD.
Os pinos referentes ao módulo de interface de entrada estão mapeados no diagrama Ladder por X0 a X15 e os de saída por Y0 e Y15. Os botões de chamada de andares do elevador foram interligados nos pinos X11 a X15 (cinco botões) e os sensores de chegada em andares nos pinos X1 a X5. O motor DC que movimenta a cabine do elevador para cima e para baixo é acionado por uma ponte H feita com relés, controlados pelos pinos Y2 (move para cima) e Y3 (move para baixo).
A lógica Ladder que controla o elevador (referente a função PlcCycle() do arquivo C gerado pela ferramenta LDMicro) é executada através do ciclo de operação do CLP apresentado na Figura 34. O tempo de varredura é definido pela Raspberry Pi e para esta aplicação foi determinado ciclos de 10ms de scan. A
79
interface de entradas e sua memória imagem (botões e sensores) são atualizadas no inicio do ciclo. A interface de saídas e sua memória de imagem (motor) são atualizadas no fim do ciclo.
O ciclo de operação foi definido testando o tempo em que a Raspberry Pi leva para executar a função PlcCycle(). Portanto, esse tempo pode variar conforme o tamanho de código gerado a partir da lógica do diagrama Ladder desenvolvido para o controle discreto do processo.
Inicialização
Leitura das entradas
Atualização da
memória imagem das
entradas
Processa programa
Elevador Industrial
PLCCycle()
Atualizar as saídas
Atualização da
memória imagem das
saídas
Ciclo de
10msLógica Ladder
Inicializa HALCamada de abstração de Hardware
Inicializa funções e características
referente a Raspberry Pi e ao CPLD.
Botões de chamada (XA11-XA15) e
Sensores de andares (XA1-XA5)
Acionamento motor
YB2 (move para cima)
YB3 (move para baixo)
Memória de controle
interna
Memória de controle
interna
Figura 34 – Ciclo de operação do CLP.
Por fim, o programa foi executado e testado através da
montagem do sistema apresentado na Figura 35.
80
Figura 35 – Montagem do sistema.
6 CONCLUSÃO E TRABALHOS FUTUROS
Este trabalho apresentou uma proposta de integração de microcontroladores e dispositivos lógicos programáveis para desenvolvimento de Controladores Lógicos Programáveis. Tal proposta visou integrar esses dispositivos de tal maneira que o microcontrolador fosse a CPU e a memória do CLP, sendo responsável por processar as instruções e guardar informações de um programa portado da linguagem Ladder. Já o PLD se comunica com o microcontrolador e gerencia os elementos periféricos do CLP.
A proposta foi validada através de dois estudos de caso. O primeiro apresentou o desenvolvimento de uma camada de abstração de hardware para interpretação da lógica de diagramas Ladder em plataformas microcontroladas com sistemas operacionais embarcados capazes de executar códigos em linguagem C ANSI. Esta implementação utilizou o LDMicro, um software livre e de código aberto para criação de diagramas Ladder, capaz de gerar código em linguagem C ANSI a partir da lógica de controle do Ladder. O código gerado foi portado para rodar em duas plataformas microcontroladas. Uma delas, a Raspberry Pi, faz parte da implementação do segundo estudo de caso. A validação foi feita através de um experimento prático de controle discreto de um protótipo de uma célula de manufatura de envasamento de garrafas.
A abordagem apresentada neste primeiro estudo de caso buscou explorar o potencial do software LDMicro como uma ferramenta útil e de baixo custo para desenvolver lógica de controle de processos em diagramas Ladder para qualquer plataforma microcontrolada que suporte programação em linguagem C ANSI. Sabendo também que o LDMicro é um software livre, de código aberto e sem fins comerciais, ele se torna bastante útil para aplicações acadêmicas na área de mecatrônica.
O segundo estudo de caso foi apresentado a integração de um sistema microcontrolado (Raspberry Pi) com um dispositivo lógico programável (CPLD MAX V) para fins de controle discreto de processos industriais, tal como num CLP comercial. Para isso, foi desenvolvido um protocolo através da interface SPI para que o microcontrolador se comunique com o PLD. No PLD, foi
82
desenvolvida uma estrutura de hardware composta por três blocos: o bloco SPI que implementa a interface SPI no lado do PLD (no microcontrolador já existe esta interface); o bloco de controle que processa os dados do protocolo de comunicação; e o bloco de periféricos compostos por módulos de entrada e saídas digitais e PWMs, que representam as interfaces de entrada e saída de um CLP. Como resultado deste estudo, foi desenvolvida uma lógica de controle em Ladder para um elevador industrial ao qual foi executado pelo conjunto Raspberry Pi e CPLD MAX V, controlando um protótipo do elevador.
A estrutura de hardware do CPLD foi elaborada de forma que o projeto possa ser expandido conforme a capacidade do PLD e da aplicação exigida no processo externo. Isto contribui para a utilização de PLDs como expansão de periféricos e, sobretudo a capacidade de reconfiguração de hardware, numa abordagem modular visando ao crescimento da solução através da adição de novos recursos periféricos conforme a capacidade do PLD e a sua aplicação.
A escolha do CPLD utilizado para elaboração deste trabalho foi devido a disponibilidade de recursos, principalmente pelo uso de um kit didático de um CPLD MAXV da Altera desenvolvido no projeto “FPGA para Todos” do Instituto Federal de santa Catarina. O fator de baixo custo do CPLD também foi um item importante para decisão do dispositivo utilizado. Além disso, este componente atendeu as necessidades de recursos de hardware para validação da solução proposta neste trabalho.
Os módulos PWMs desenvolvidos não foram utilizados na validação do projeto com o elevador industrial. Entretanto, o mesmo foi testado em outras aplicações didáticas para o projeto “FPGA para Todos”.
6.1 Trabalhos futuros
Como proposta de trabalhos futuros a solução apresentada poderá ser expandida utilizando um PLD de maior capacidade de recursos de hardware, tal como um FPGA. Como isso, novos módulos de periféricos poderão ser adicionados possibilitando novas funcionalidades para a solução.
83
Como o FPGA possui uma arquitetura que pode alcançar níveis de integração e desempenho muito superiores aos CPLDs, uma nova abordagem pode também ser explorada. É possível, por exemplo, implementar nele uma CPU. A Altera, como em outros fabricantes, disponibilizam implementações de processadores em software, tanto de arquiteturas consagradas como de processadores ARM quanto de versões próprias, que podem ser embarcados nos FPGAs. No caso da fabricante Altera, ela disponibiliza versões gratuita e paga do seu processador NIOS II, além de um conjunto de ferramentas para facilitar o desenvolvimento de projetos em FPGA com o uso de seu processador.
Essa abordagem possibilita integrar em um único CI todos os recursos de hardware de um CLP, dispensando o uso de uma unidade de processamento externo. Com isso, se ganha em desempenho e em implementações mais compactas.
Além disso, o foco do presente trabalho foi explorar as tecnologias microcontroladas para utilização de um dispositivo disseminado na academia que permitisse a exploração de recursos avançados existentes nas Single Board Computers (SBCs) atuais. O emprego do SO Linux permite também o aproveitamento de diversas bibliotecas de código aberto disponíveis para processamento matemático e algoritmos de controle sofisticados.
O uso de Lógica programável além da possibilidade de expansão de dos periféricos (I/Os) possibilita o emprego de periféricos de alta velocidade aliada a possibilidade de inclusão de processamento rápido por módulo em hardware, implementados em linguagem VHDL.
REFERÊNCIAS BIBLIOGRÁFICAS
ALTERA. Implementing the Top Five Control-Path Applications with Low-Cost, Low-Power CPLDs (publicado em fevereiro de 2011). Disponível em: <http://www.altera.com/literature/wp/wp-01146-control-path-apps.pdf#page=1>. Acesso em: 05 de maio de 2013. ARM. Documentation home page. Disponível em: <http://infocenter.arm.com/help/index.jsp>. Acesso em: 01 abril 2013. ATMEL. Application note - MCU Port Expansion Using ATF15xx CPLDs (publicado em setembro de 2006). Disponível em: < http://www.atmel.com/Images/doc3635.pdf>. Acesso em: 05 de maio de 2013. CHMIEL, M. MOCHA, J. HRYNKIEWICZ, E. MILIK, A. Central Processing Units for PLC implementation in Virtex-4 FPGA. 18
th IFAC World Congress 2011. Milano, Italy. 2011.
DA COSTA, C.; MESQUITA, L.; PINHEIRO, E. Elementos de Lógica Programável com VHDL e DSP - Teoria e Prática. 1. ed. São Paulo: Editora Érica, 2011. v. 1. 296p . DA COSTA, CESAR . Implementação de CLP em FPGA. Mecatrônica Atual, v. 4, p. 50-60, 2006. DA COSTA, CESAR . Projetando Controladores Digitais com FPGA. 1. ed. São Paulo: Novatec Editora Ltda, 2006. v. 1. 160p . DIGI. ConnectCore® 9P 9215 - Highly integrated, network-enabled core module. Disponível em: <http://www.digi.com/products/wireless-wired-embedded-solutions/solutions-on-module/connectcore/connectcore9p9215>. Acesso em: 05 de Maio 2013. FLOYD, Thomas L. Sistemas Digitais: Fundamentos e Aplicações. Tradução: José Lucimar do Nascimento. ISBN 978-85-7780-107-7. 9. Ed. Porto Alegre: Bookman, 2007. 888 p.
85
FRANCHI, Claiton M.; CAMARGO, Valter L. A. de. Controladores Lógicos Programáveis - Sistemas Discretos. 1ª Ed. São Paulo: Editora Érica Ltda., 2008. ISBN 978-85-365-0199-4. GEORGINI, M. Automação Aplicada - Descrição e Implementação de Sistemas Sequenciais com PLCs. 9ª ed. São Paulo: Editora Érica Ltda., v. I, 2008. ISBN 978-85-7194-724-5. HIDALGO, A. R. ; OLIVEIRA, Levi Pedro Barbosa de; Oliveira, L. R. . Linguagem Ladder para programar microcontroladores em aplicações como controladores industriais programáveis. In: XVII CONGRESSO BRASILEIRO DE AUTOMÁTICA, 2008, JUIZ DE FORA. XVII CONGRESSO BRASILEIRO DE AUTOMÁTICA, 2008. LINUX FOR DEVICES. Snapshot of the Embedded Linux market (Abril, 2007). Disponível em: <http://www.Linuxfordevices.com/c/a/Linux-For-Devices-Articles/Snapshot-of-the-Embedded-Linux-market-April-2007/>. Acesso em: 01 abril 2013. PEREIRA, Fábio. Tecnologia ARM: microcontroladores de 32 bits. 1º ed. ISBN 978-85-365-0170-3. São Paulo: Érica, 2007. PEREIRA, S. L. Controladores Lógicos Programáveis (Apostila). São Paulo: EPUSP, 2003. PINTO, P. H. Funcionamento de um Controlador Lógico Programável. Revista Controle de Contaminação. São Paulo. N. 110. P. 31-34. Junho/2008. RASPBERRY PI FOUNDATION. Wiki. Disponível em: < http://www.raspberrypi.org/wiki-2>. Acesso em: 05 de Maio de 2013. ROHDE, R. A.; MOLINAR, F.; KIECKOW, F. Projeto de um CLP de baixo custo com programação em LADDER. In: COBENGE 2011, 2011, Blumenau. Cobenge 2011, 2011. v. 1.
86
TEIXEIRA, M. A. Técnicas de Reconfigurabilidade dos FPGAs da Família APEX 20K Altera. 2002. 127 p. Dissertação (mestrado em Ciências de Computação e Matemática Computacional) - Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos, 2002. TOCCI, Ronald J.; WIDMER, Neal S.; MOSS, Gregory L. Sistemas digitais: princípios e aplicações. Tradução: Cládia Martins. Revisão Técnica: João Antonio Martino. ISBN 978-85-7605-095-7. 10. Ed. São Paulo: Pearson Prentice Hall, 2007. WESTHUES, Jonathan. Ladder Logic for PIC and AVR (Agosto de 2010). Disponível em: <http://cq.cx/Ladder.pl>. Acesso em: 05 de Maio 2013. Wiki. BBC BASIC (última modificação 25 de março 2013). Disponível em: <http://pt.wikipedia.org/wiki/BBC_BASIC>. Acesso em: 15 de maio de 2013. XILINX. An SMBus/I2C-Compatible Port Expander (publicado em junho de 2008). Disponível em: < http://www.xilinx.com/support/documentation/application_notes/xapp799.pdf>. Acesso em: 05 de maio de 2013.
APÊNDICES
88
APÊNDICE A – Diagrama Ladder da lógica de controle do elevador industrial
LDMicro export text
for 'ANSI C Code, 10.0 ms cycle time
LADDER DIAGRAM:
|| ||
|| XA14 RA1 RsubindoAte4 ||
1 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| . | RA1 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA15 RA1 RsubindoAte5 ||
2 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA1 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA13 RA1 RsubindoAte3 ||
3 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA1 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA12 RA1 RsubindoAte2 ||
4 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA1 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA14 RA5 RdescendoAte4 ||
5 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA5 ||
89
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA13 RA5 RdescendoAte3 ||
6 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA5 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA11 RA5 RdescendoAte1 ||
7 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA5 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA12 RA5 RdescendoAte2 ||
8 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA5 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA11 RA2 RdescendoAte1 ||
9 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA2 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA15 RA4 RsubindoAte5 ||
10 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA4 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA3 RdescendoAte3 RA3 ||
90
11 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RdescendoAte3 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA4 RdescendoAte4 RA4 ||
12 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RdescendoAte4 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA4 RsubindoAte4 RA4 ||
13 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RsubindoAte4 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA3 RsubindoAte3 RA3 ||
14 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RsubindoAte3 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA2 RsubindoAte2 RA2 ||
15 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RsubindoAte2 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA5 RsubindoAte5 RA5 ||
16 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RsubindoAte5 ||
|| +-------(R)-------||
|| ||
|| ||
91
|| ||
|| ||
|| XA1 RdescendoAte1 RA1 ||
17 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RdescendoAte1 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA2 RdescendoAte2 RA2 ||
18 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RdescendoAte2 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA15 RA3 RsubindoAte5 ||
19 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA3 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA15 RA2 RsubindoAte5 ||
20 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA2 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA14 RA2 RsubindoAte4 ||
21 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA2 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA13 RA2 RsubindoAte3 ||
22 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA2 ||
92
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA14 RA3 RsubindoAte4 ||
23 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA3 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA12 RA3 RdescendoAte2 ||
24 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA3 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA12 RA4 RdescendoAte2 ||
25 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA4 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA11 RA4 RdescendoAte1 ||
26 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA4 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA11 RA3 RdescendoAte1 ||
27 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA3 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| XA13 RA4 RdescendoAte3 ||
93
28 ||-------]/[--------------] [------+-------(S)-------||
|| | ||
|| | RA4 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
|| ||
|| RdescendoAte1 YB0 ||
29 ||-------] [------+------------------------( )-------||
|| | ||
|| RdescendoAte2 | ||
||-------] [------+ ||
|| | ||
|| RdescendoAte3 | ||
||-------] [------+ ||
|| | ||
|| RdescendoAte4 | ||
||-------] [------+ ||
|| ||
|| ||
|| ||
|| ||
|| RsubindoAte2 YB1 ||
30 ||-------] [------+------------------------( )-------||
|| | ||
|| RsubindoAte3 | ||
||-------] [------+ ||
|| | ||
|| RsubindoAte4 | ||
||-------] [------+ ||
|| | ||
|| RsubindoAte5 | ||
||-------] [------+ ||
|| ||
|| ||
|| ||
|| ||
|| XA15 XA11 RA1 ||
31 ||-------]/[--------------]/[------+-------(S)-------||
|| | ||
|| | RA2 ||
|| +-------(R)-------||
|| | ||
|| | RA3 ||
|| +-------(R)-------||
|| | ||
|| | RA4 ||
|| +-------(R)-------||
|| | ||
|| | RA5 ||
94
|| +-------(R)-------||
|| | ||
|| | RsubindoAte2 ||
|| +-------(R)-------||
|| | ||
|| | RsubindoAte3 ||
|| +-------(R)-------||
|| | ||
|| | RsubindoAte4 ||
|| +-------(R)-------||
|| | ||
|| | RsubindoAte5 ||
|| +-------(R)-------||
|| | ||
|| | RdescendoAte1 ||
|| +-------(R)-------||
|| | ||
|| | RdescendoAte2 ||
|| +-------(R)-------||
|| | ||
|| | RdescendoAte3 ||
|| +-------(R)-------||
|| | ||
|| | RdescendoAte4 ||
|| +-------(R)-------||
|| ||
|| ||
|| ||
||------[END]----------------------------------------||
|| ||
|| ||
E/S ATRIBUIDA:
Nome | Tipo | Pino
----------------------------+--------------------+------
XA11 | entrada digital | (sem atribuição)
XA12 | entrada digital | (sem atribuição)
XA13 | entrada digital | (sem atribuição)
XA14 | entrada digital | (sem atribuição)
XA15 | entrada digital | (sem atribuição)
XA1 | entrada digital | (sem atribuição)
XA2 | entrada digital | (sem atribuição)
XA3 | entrada digital | (sem atribuição)
XA4 | entrada digital | (sem atribuição)
XA5 | entrada digital | (sem atribuição)
YB0 | saída digital | (sem atribuição)
YB1 | saída digital | (sem atribuição)
RA1 | rele interno |
RA2 | rele interno |
95
RA3 | rele interno |
RA4 | rele interno |
RA5 | rele interno |
RdescendoAte1 | rele interno |
RdescendoAte2 | rele interno |
RdescendoAte3 | rele interno |
RdescendoAte4 | rele interno |
RsubindoAte2 | rele interno |
RsubindoAte3 | rele interno |
RsubindoAte4 | rele interno |
RsubindoAte5 | rele interno |
96
APÊNDICE B – Tutorial de uso do HAL para o CLP
Neste roteiro será apresentado o uso da camada de abstração de hardware (Hardware Abstract Layer – HAL) criada para portar a lógica de diagramas Ladder, elaborados na ferramenta LDMicro, para o CLP desenvolvido neste trabalho. O processo consiste na criação de um diagrama Ladder, conversão da lógica deste diagrama para um código em linguagem C, apresentação da estrutura de arquivos do HAL e compilação do projeto para o CLP.
Os passos deste roteiro serão exemplificados com o experimento apresentado no item 5.2.6 do capítulo 5 deste trabalho.
Passo 1 – Criação de um diagrama Ladder
Neste passo é necessário utilizar a ferramenta LDMicro
que pode ser adquirida abertamente no site do desenvolvedor: http://cq.cx/Ladder.pl. Neste endereço da internet está disponível também toda documentação das funcionalidades do LDMicro, bem como um tutorial de utilização do mesmo. Na Figura 36 é mostrada a tela do LDMicro com o diagrama Ladder aberto da lógica de controle do elevador industrial que foi apresentado por completo no APÊNDICE A.
97
Figura 36 – Tela do LDMicro com o diagrama Ladder da lógica de
controle do elevador industrial.
No processo de criação do diagrama Ladder é preciso
saber que as interfaces de entradas e saídas do CLP deste trabalho foram mapeadas com os nomes XA0 a XA15 para os contatos (entradas) e YB0 a YB15 para os relés (saídas). Portanto, no desenvolvimento do diagrama é preciso seguir está regra de nomes para que o HAL entenda qual interface se está utilizando no CLP.
Passo 2 – Conversão da lógica do diagrama Ladder para um código em linguagem C
Primeiramente é preciso configurar o LDMicro para gerar
um código C ANSI clicando em “Configurações” na barra de menus, acessar o item “Microcontrolador” e selecionar o item “ANSI C Code”, conforme mostra a Figura 37.
98
Figura 37 – Configurando o LDMicro para gerar um código C ANSI.
Depois de feito isso, basta converter este diagrama em um
arquivo em linguagem C, clicando no item “Compilar” da barra de menus da ferramenta, conforme mostra a Figura 38. Isto criará um arquivo em C que conterá a lógica do diagrama ladder em uma função chamada “PlcCycle()”, como apresentado no item 5.1.3 do capítulo 5.
99
Figura 38 – Convertendo o diagrama em um arquivo em linguagem
C.
O arquivo “projetoElevador.c” gerado pelo LDMicro e salvo
no computador será então copiado para a pasta onde se encontra a estrutura de arquivos do HAL do CLP.
Passo 3 - Apresentação da estrutura de arquivos do HAL
O HAL desenvolvido para o CLP foi elaborado de forma
estruturada em arquivos que contém as funções de controle das interfaces mapeadas do CLP, as funções de controle das memórias imagens de entradas e saídas do CLP e as funções específicas de controle dos periféricos da plataforma. Os arquivos foram divididos em duas pastas, “headers” e “sources”, em que contém os arquivos de protótipos (declarações) das funções e os arquivos com a definição (conteúdo) das funções, respectivamente, conforme mostra a Figura 39. Além disso, o HAL contém um arquivo “Makefile” que contém as regras de compilação do projeto para a plataforma do CLP.
100
Os arquivos “ladder.h” e “ladder.c” são referentes as funções de controle das interfaces mapeadas do CLP, os arquivos “Memoria.h” e “Memoria.c” são referentes as funções de controle das memórias imagens de entradas e saídas do CLP e os arquivos “Plataforma.h” e “Plataforma.c” são referentes as funções específicas de controle dos periféricos da plataforma.
O arquivo “timed_main.c” contém a função principal “main()” que chama a função “PlcCycle()” do arquivo gerado no passo anterior. Além disso, é na função principal que está definido o ciclo de operação do CLP.
Figura 39 – Arquivos que compõe o HAL.
101
Passo 4 – Compilando o projeto Entendido a estrutura do HAL, para utilizá-lo basta copiar o
arquivo “projetoElevador.c” criado no passo 2 na pasta “source” do HAL. Feito isso e seguindo as instruções deste tutorial, basta copiar o HAL para o CLP utilizando um aplicativo que conecte a Raspberry Pi via SSH e compilá-lo na plataforma utilizando o comando “make” do Linux. Um arquivo binário é gerado e o mesmo pode ser executado no CLP para rodar a lógica do diagrama Ladder desenvolvido. A Figura 40 mostra o processo de compilação do HAL na plataforma do CLP.
Figura 40 – Processo de compilação do HAL na plataforma do CLP.