de forma que toda as entradas de dados, como valores de temperatura e sinalização dos sensores de chama e gás, são processados pelo JavaScript e mostrados na página Web, assim como outras informações julgadas importantes, como a data atual.
Em relação a forma como o usuário acessa a aplicação Web, toda o código da página (HTML, CSS, JavaScript) foi inserido em um script escrito em Python, que ficou responsável por criar um Web Server através de uma biblioteca nativa do Python e hospedar em determinada porta do endereço de rede do Raspberry a página Web, permitindo assim que a mesma fosse acessada por qualquer dispositivo conectado à rede. Através deste
script feito em Python é que também foi possível realizar o stream da câmera.
4.3
O Controlador Principal
Para exercer a função de controlador principal utilizou-se um Raspberry Pi, que agindo com um micro computador permite a instalação de um sistema operacional. Baseado em linux, o mais famoso sistema operacional para Raspberry é o Raspbian, uma variante de outro sistema Linux que foi otimizado para funcionar em computadores com arquiteturas de hardwares como o Raspberry Pi. Este sistema operacional livre permite fazer com o Raspberry praticamente tudo que se faz com um computador pessoal, como acessar a internet, ouvir músicas, assistir vídeos e até rodar alguns jogos, possuindo cerca de 35 mil pacotes pré-compilados de fácil instalação (QUEIROZ et al., 2016).
Outra função disponível com este sistema é a criação de um script, que segundo COSTA (2010) pode ser entendido como um roteiro composto por um código-fonte, um arquivo que contém um conjunto de comandos sequenciais, que são executados por um interpretador da linguagem pela qual o script foi escrito, e então executa cálculos, tarefas e funções do sistema operacional. Para que então o Raspberry execute todas as ações como controlador principal da residência, foi implementado um script com todas as ações que ele deve tomar e que fica rodando durante todo o tempo em que o sistema está funcionando.
Como o hardware do Raspberry Pi é limitado, o desenvolvimento do script se tornaria uma tarefa demorada, principalmente durantes os testes de funcionamento da comunicação com a aplicação móvel. A fim de facilitar esse desenvolvimento, foi utilizado um software de virtualização chamado QEMU para emular o sistema Raspbian, onde o
scriptfoi escrito e testado, para depois ser usado no Raspberry em si. QEMU (QEMU,
2018) é um software livre para virtualização de processadores, que permite emular diversos sistemas operacionais para essas arquiteturas de foma rápida. Ele opera em dois modos: • Emulação total do sistema: Neste modo o QEMU virtualiza uma arquitetura completa, com todos os processadores e demais componentes, permitindo a emulação de vários sistemas operacionais sem a necessidade de reiniciar a máquina.
46 Capítulo 4. Materiais e Métodos
compilados de uma CPU em outra CPU, de forma a facilitar a depuração e compilação cruzada.
O QEMU possui recursos como ser portátil para diversos sistemas operacionais e arqui- teturas, usa tradução dinâmica para códigos nativos com uma velocidade razoável, um acelerador de kernel e suporte para emular periféricos como portas USB. A figura 7 mostra uma tela da emulação do sistema operacional Raspbian com o QEMU.
Figura 7 – Tela do QEMU emulando Raspbian
Fonte: Autor (2018)
Após o fim do desenvolvimento da aplicação móvel, com a função de interpretar áudios e transcrevê-los para texto, o sistema já podia oferecer ao usuário uma interface para comunicação entre o mesmo e a residência, atendendo ao requisito de que os comandos fossem passados por voz. No entanto, qualquer comando que for passado ao aplicativo precisa ainda ser "ouvido e entendido"pela residência através da comunicação entre aplicação e o controlador principal, Raspberry. Seguindo o modelo cliente-servidor, o Raspberry se conecta com aplicação através do socket e age como um servidor recebendo as requisições da aplicação. O algoritmo 2 traz o pseudocódigo de como o Raspberry recebe os comandos passados pelo usuário através da aplicação. Primeiramente é definido o número de porta onde o servidor ficará esperando as requisições do cliente, e depois é criado o socket com este número de porta e o ip do Raspberry na rede. Após isto o servidor entra em um
4.3. O Controlador Principal 47
loop infinito onde fica esperando o cliente requisitar uma conexão para que ele a aceite e
comece a receber as mensagens do cliente.
Algoritmo 2: Socket Servidor
Saída: Ip do cliente conectado e a mensagem enviada 1 início
2 coloca um valor para a porta
3 cria o socket com a porta e o Ip do controlador
4 repita
5 espera requisição da aplicação
6 se aceita conexão com socket cliente então
7 recebe a mensagem do cliente
8 senão
9 diga que a conexão falhou
10 fim
11 até infinito; 12 fecha o socket
13 fim
O script então foi implementado com o socket, que permitia ao Raspberry receber os comandos da aplicação. Em seguida, era necessário escrever no script o código para que o Raspberry interpreta-se esses comandos, executando uma respectiva ação, como ascender uma lâmpada. Para que então, esse script possa ficar esperando um comando e, quando este comando for recebido, ele seja executado, foi implementado no script o problema do produtor-consumidor (também conhecido como problema do buffer limitado). Este problema, segundo Tanenbaum e Woodhull (2009) consiste no compartilhamento de um buffer por dois processos, em que um deles (produtor) adiciona dados a este buffer e o outro (consumidor), recolhe estes dados adicionados, sendo possível adaptar este problema para n produtores e consumidores. Pelo fato do buffer ter um tamanho fixo, ocorrem vezes em que o produtor o deixa cheio e, desta forma, o produtor deve ser bloqueado até o momento em que o consumidor remova alguma informação, para que haja espaço no
buffer para o produtor adicionar mais dados. Da mesma forma, o consumidor deve ser
bloqueado sempre que o buffer estiver vazio. Utilizando os conceitos deste problema, o
script do Raspberry implementa um buffer de tamanho 1, que irá guardar um comando
vindo da aplicação que será adicionado pelo produtor e, como o buffer já estará cheio com um comando, o produtor será bloqueado e o consumidor ativado, onde o comando é removido do buffer e então interpretado pelo Raspberry, que então executa a ação necessária. Este script fica executando o tempo todo, e esse processo de produzir e consumir comandos acontece constantemente. O algoritmo 3 traz o pseudocódigo da adaptação do problema do produtor-consumidor para atender ao funcionamento do Raspberry.
48 Capítulo 4. Materiais e Métodos
Algoritmo 3: Produtor-Consumidor para o controlador princi-
pal
1 PRODUTOR:
2 início
3 se produtor não estiver bloqueado então
4 espera comando da aplicação adiciona comando ao buffer
5 senão 6 bloqueia o produtor 7 desbloqueia o consumidor 8 chama o consumidor 9 fim 10 fim 11 CONSUMIDOR: 12 início
13 se consumidor não estiver bloqueado então
14 retira comando do buffer interpreta o comando
15 senão 16 bloqueia o consumidor 17 desbloqueia o produtor 18 chama o produtor 19 fim 20 fim
Após a finalização do script para o Raspberry, foi então desenvolvido a plataforma para testar todo o sistema, que envolveu também as conexões elétricas dos dispositivos.