Resultados para: “Informática e Tecnologia”

CAPÍTULO 6

Entrada e saída

O Arduino trata da chamada computação física. Isso significa ligar circuitos eletrônicos à placa do Arduino. Portanto, é necessário que você compreenda a usar as várias opções de conexão dos seus pinos.

As saídas podem ser digitais, apresentando valores de 0 volts ou 5 volts, ou analógicas, apresentando qualquer valor entre 0 e 5 volts – embora não seja tão simples assim, como veremos. Por outro lado, as entradas podem ser digitais

(verificar se um botão foi apertado ou não) ou analógicas (verificar o valor medido por um sensor luminoso).

Em um livro que trata basicamente de software e não de hardware, procuraremos não nos envolver com discussões aprofundadas de eletrônica. Neste capítulo, entretanto seria útil se você pudesse dispor de um multímetro e de um pedaço de fio rígido para compreender melhor o que está acontecendo.

OBJETIVOS DE APRENDIZAGEM

Entender como funcionam as saídas e as entradas digitais.

Aprender a estabelecer a comunicação entre o Arduino e um computador PC.

CAPÍTULO 4

Funções

Este capítulo dedica-se principalmente aos tipos de função que você mesmo pode escrever. Estas funções são diferentes das funções internas, tais como digitalwrite e delay, que já foram predefinidas para você.

A razão pela qual você precisa saber como escrever as suas próprias funções é que, quando os sketches começam a se tornar complicados, as funções setup e loop crescem até se tornarem longas e complexas, ficando difícil de entender a maneira como funcionam.

O maior problema no desenvolvimento de software de qualquer tipo é saber lidar com a complexidade. Os melhores programadores escrevem software que é fácil de ser lido e compreendido, requerendo pouca explicação.

As funções são uma ferramenta chave para criar sketches de fácil compreensão. Elas podem ser modificadas sem dificuldade e sem risco de a coisa toda se transformar em uma grande confusão.

OBJETIVOS DE APRENDIZAGEM

Entender o que é uma função.

Aprender como passar parâmetros a funções.

CAPÍTULO 8

Armazenamento de dados

Quando você atribui valores às variáveis, esses dados são conservados na memória somente enquanto a placa do Arduino estiver ligada. No momento em que você desligá-lo ou der reset, todos os dados serão perdidos.

Neste capítulo, iremos examinar algumas maneiras de conservar esses dados.

OBJETIVOS DE APRENDIZAGEM

Aprender maneiras de armazenar dados depois de desligar o Arduino.

Aprender a armazenar dados na memória flash.

Aprender a usar a memória EEPROM para armazenar dados permanentes que podem ser alterados.

Aprender o modo mais eficiente de representar os dados quando eles são maiores que o espaço disponível.

Monk_C08.indd 111

31/05/2017 09:50:16

112

PROGRAMAÇÃO COM ARDUINO

Constantes

Se os dados que você desejar armazenar são sempre os mesmos, então você poderá simplesmente inicializar os dados toda vez que o Arduino começar a executar um sketch. Um exemplo dessa abordagem é o caso do array de letras do seu tradutor de código Morse do

CAPÍTULO 11

C++ e bibliotecas

Os Arduinos são simples microcontroladores. Na maior parte do tempo, os sketches de Arduino são bem pequenos, de modo que o uso da linguagem

C de programação funciona muito bem. Entretanto, a linguagem de programação do Arduino é, na realidade, C++ em vez de C. A linguagem C++ é uma extensão da linguagem C e contém algo denominado orientação a objeto.

OBJETIVOS DE APRENDIZAGEM

Aprender alguns fundamentos da linguagem C++ e de orientação a objeto.

Examinar mais de perto a biblioteca LCD.

Criar uma biblioteca simples para entender os conceitos que estão por trás.

Monk_C11.indd 163

31/05/2017 09:52:02

164

PROGRAMAÇÃO COM ARDUINO

Orientação a objeto

Este é apenas um pequeno livro, de modo que uma explicação aprofundada da linguagem

C++ de programação está além de seus propósitos. No entanto, o livro cobrirá alguns fundamentos de C++ e de orientação a objeto, sabendo que o seu objetivo principal é aumentar o encapsulamento dos programas. O encapsulamento mantém juntas as coisas relevantes, algo que torna a linguagem C++ muito adequada para escrever bibliotecas como as que você usou nos sketches de Ethernet e de LCD em capítulos anteriores.

CAPÍTULO 1

Este é o Arduino

O Arduino é uma plataforma de microcontrolador que atraiu a imaginação dos entusiastas de eletrônica. Sua facilidade de uso e sua natureza aberta fazem dele uma ótima opção para qualquer um que queira realizar projetos eletrônicos.

Basicamente, permite que você conecte circuitos eletrônicos a seus terminais, permitindo que ele controle coisas – como, por exemplo, ligar ou desligar dispositivos, como lâmpadas e motores, ou medir grandezas físicas, como luz e temperatura. Essa é a razão pela qual algumas vezes dizemos que o Arduino realiza uma computação física (concreta). Como os Arduinos podem ser conectados a um computador por meio de um cabo USB (universal serial bus, ou barramento serial universal), isso significa também que você pode usar o Arduino como placa de interface e controlar esses mesmos dispositivos a partir de seu computador.

OBJETIVOS DE APRENDIZAGEM

Conhecer microcontroladores e placas de desenvolvimento.

Conhecer uma placa de Arduino.

164

Parte III

Padrões para Desenvolvimento Guiado por Testes

Tente ambas as formas. Veja se você se sente diferente; programe diferente quando tiver dois testes que não funcionam. Responda conforme o caso.

Objeto simulado (Mock Object)

Como você testa um objeto que se baseia em um recurso caro ou complicado? Crie uma versão faz de conta do recurso que responde com constantes.

Há ao menos um material com valor equivalente a um livro sobre Objeto

Simulado1, mas isso servirá como uma introdução. O exemplo clássico é um banco de dados. Bancos de dados levam um longo tempo para iniciarem; são difíceis de manter limpos; e, se estão localizados em um servidor remoto, amarram seus testes a um local físico em uma rede. O banco de dados também é uma fonte fértil de erros no desenvolvimento.

A solução é não usar um banco de dados real na maior parte do tempo. A maioria dos testes é escrita em termos de um objeto que age como um banco de dados, mas está apenas assentado na memória. public void testOrderLookup() {

98

Parte I

O Exemplo Financeiro

Roseta* para gerações futuras apreciarem nossa genialidade. Pense, ó pense, em nossos leitores.

O teste, nesse caso, é mais longo que o código. O código é o mesmo código em Money. (Será que eu ouvi uma classe abstrata ao longe?)

Sum public Expression plus(Expression addend) { return new Sum(this, addend);

}

$5 + 10 CHF = $10 se a taxa é 2:1

$5 + $5 = $10

Retornar Money de $5 + $5

Bank.reduce( Money )

Reduzir Money com conversões

Reduce(Bank, String)

Sum.plus

Expression.times

Você terminará, aproximadamente, com o mesmo número de linhas no código do teste e no código modelo quando implementar TDD. Para TDD fazer sentido em termos de economia, você precisará ser capaz de escrever o dobro de linhas por dia do que escrevia antes, ou escrever metade daquela quantidade de linhas para a mesma funcionalidade. Terá que medir e ver que efeitos TDD tem por sua própria prática. Certifique-se, no entanto, de considerar tempos de depuração, integração e explicação em suas métricas.

$5 + 10 CHF = $10 se a taxa é 2:1

Apêndice

I

Diagramas de Influência

Este livro contém muitos exemplos de diagramas de influência. A ideia dos diagramas de influência é obtida da excelente série Quality Software Manage1 ment de Gerald Weinberg, particularmente do Livro 1: Systems Thinking . O propósito de um diagrama de influência é ver como os elementos de um sistema afetam um ao outro.

Diagramas de influência têm três elementos:

• Atividades, anotadas como uma palavra ou frase curta.

• Conexões positivas, anotadas como uma flecha direcionada entre duas atividades, significando que mais da atividade origem tende a criar mais da atividade destino, ou menos da atividade de origem tende a criar menos da atividade destino.

• Conexões negativas, anotadas como flechas direcionadas entre duas atividades com um círculo sobre ela, significando que mais da atividade de origem tende a criar menos da atividade destino, ou menos da atividade de origem tende a criar mais da atividade destino.

Um monte de palavras para um conceito simples. As Figuras A.1 a A.3 fornecem alguns exemplos.

66

Parte I

O Exemplo Financeiro

Dollar

Money times(int multiplier) { return Money.dollar(amount * multiplier);

}

Não há um jeito óbvio de fazê-las idênticas. Às vezes você tem que voltar atrás para seguir em frente, como quando resolvemos um Cubo de Rubik. O que acontece se nós otimizarmos os métodos fábrica? (Eu sei, eu sei, nós chamamos o método fábrica pela primeira vez apenas um capítulo atrás. Frustrante, não é?)

Franc

Money times(int multiplier) { return new Franc(amount * multiplier, "CHF");

}

Dollar

Money times(int multiplier) { return new Dollar(amount * multiplier, "USD");

}

Em Franc, entretanto, sabemos que a variável de instância de moeda é sempre

“CHF”, então podemos escrever:

Franc

Money times(int multiplier) { return new Franc(amount * multiplier, currency);

}

Isso funciona. O mesmo truque funciona em Dollar:

Dollar

Money times(int multiplier) { return new Dollar(amount * multiplier, currency);

}

Estamos quase lá. Realmente importa se temos um Franc ou um Money? Poderíamos pensar sobre isso cuidadosamente, dado nosso conhecimento sobre o sistema, mas temos código limpo e temos testes que nos dão confiança de que o código limpo funciona. Em vez de usar minutos de raciocínio suspeito, podemos apenas perguntar para o computador fazendo as mudanças e rodando os testes.

56

Parte I

O Exemplo Financeiro

Podemos dar um passo na direção de conciliá-los, fazendo ambos retornarem um

Money:

Franc

Money times(int multiplier) { return new Franc(amount * multiplier);

}

Dollar

Money times(int multiplier) { return new Dollar(amount * multiplier);

}

O próximo passo não é tão óbvio. As duas subclasses de Money não estão fazendo o suficiente para justificarem sua existência, logo, gostaríamos de eliminá-las. Mas, não podemos fazer isso em um grande passo, pois não seria uma demonstração muito eficaz de TDD.

Certo, estaremos um passo mais próximos de eliminarmos as subclasses se houver menos referências diretas às subclasses. Podemos introduzir um método fábrica em Money que retorne um Dollar. Usaremos algo assim: public void testMultiplication() {

Dollar five = Money.dollar(5); assertEquals(new Dollar(10), five.times(2)); assertEquals(new Dollar(15), five.times(3));

}

A implementação cria e retorna um Dollar:

Money static Dollar dollar(int amount) { return new Dollar(amount);

}

Mas, queremos que as referências a Dollars desapareçam, logo precisamos mudar a declaração no teste: public void testMultiplication() {

✐

✐

Ierusalimschy — Prova 4 — 13/4/2015 — Maluhy&Co. — página 313

30

Gerenciando Recursos

Na nossa implementação de arrays de booleanos do capítulo anterior, nós não precisamos nos preocupar com a gerência de recursos. Aqueles arrays precisam apenas de memória. Cada userdatum que representa um array tem a sua própria memória, que é gerenciada por Lua. Quando um array se torna lixo (isto é, inacessível pelo programa), Lua eventualmente o coleta e libera a sua memória.

A vida nem sempre é tão fácil. Algumas vezes, um objeto precisa de outros recursos além de memória bruta, como descritores de arquivos, descritores de janelas e coisas do gênero (frequentemente, esses recursos também são apenas memória, mas gerenciada por alguma outra parte do sistema). Nesses casos, quando o objeto se tornar lixo e for coletado, esses outros recursos também deverão ser liberados de alguma forma.

Como vimos na Seção 17.6, Lua provê finalizadores sob a forma do metamétodo

✐

✐

Ierusalimschy — Prova 4 — 13/4/2015 — Maluhy&Co. — página 237

23

A Biblioteca do Sistema Operacional

A biblioteca do Sistema Operacional inclui funções para a manipulação de arquivos

(não de fluxos), para a obtenção da data e da hora correntes e outras funcionalidades relacionadas ao sistema operacional. Ela é definida na tabela os. Essa biblioteca paga um preço pela portabilidade de Lua: como Lua é escrita em ANSI C, ela usa apenas as funcionalidades que o padrão ANSI oferece. Muitas funcionalidades de

SO, como a manipulação de diretórios e de soquetes (sockets), não fazem parte desse padrão; assim, a biblioteca do sistema operacional não as provê. Há outras bibliotecas Lua, não incluídas na distribuição principal, que proveem acesso estendido ao

SO. Alguns exemplos são a biblioteca posix, que oferece toda a funcionalidade do padrão POSIX.1 para Lua; luasocket, para suporte a funcionalidades de rede; e

LuaFileSystem, para a manipulação básica de diretórios e atributos de arquivos.

✐

✐

Ierusalimschy — Prova 4 — 13/4/2015 — Maluhy&Co. — página 181

17

Tabelas Fracas e Finalizadores

Lua faz gerenciamento automático de memória. Os programas criam objetos (tabelas, threads etc.), mas não há nenhuma função para removê-los. Lua remove automaticamente os objetos que se tornam lixo, usando coleta de lixo. Isso libera você da maioria das obrigações de gerenciamento de memória e, mais importante, o libera da maioria dos erros relacionados a essa atividade, como ponteiros soltos (dangling pointers) e vazamentos de memória.

O uso de um coletor de lixo real significa que Lua não tem problemas com ciclos.

Você não precisa de nenhuma ação especial ao usar estruturas de dados cíclicas; elas são coletadas como quaisquer outros dados. No entanto, algumas vezes, mesmo o coletor mais esperto precisa da sua ajuda. Nenhum coletor de lixo permite que você esqueça todas as preocupações quanto à gerência de recursos, como o acúmulo

(hoarding) de memória e de recursos externos.

✐

✐

Ierusalimschy — Prova 4 — 13/4/2015 — Maluhy&Co. — página 169

16

Programação Orientada a Objetos

Uma tabela em Lua é um objeto em mais de um sentido. Como objetos, as tabelas têm um estado e uma identidade (um self ) que não tem relação com seus valores; especificamente, dois objetos (tabelas) com o mesmo valor são objetos diferentes, enquanto um objeto pode ter valores diferentes em momentos distintos. Ainda como objetos, as tabelas têm um ciclo de vida independente de quem as criou ou de onde foram criadas.

Os objetos têm as suas próprias operações. As tabelas também podem ter operações, como no seguinte fragmento de código:¹

Account = {balance = 0} function Account.withdraw (v)

Account.balance = Account.balance - v end

Essa definição cria uma nova função e a armazena em um campo withdraw do objeto

Account. Em seguida, podemos chamá-la como em

Account.withdraw(100.00)

1. Mantivemos no exemplo desta seção, como em todos os demais exemplos do livro, o código original em inglês. Este exemplo refere-se a uma conta bancária (Account), com um saldo (balance), operações de retirada (withdraw) e depósito (deposit). (N.T.)

✐

✐

Ierusalimschy — Prova 4 — 13/4/2015 — Maluhy&Co. — página 122

12

Arquivos de Dados e Persistência

Quando lidamos com arquivos de dados, é geralmente muito mais fácil escrever os dados do que lê-los de volta. Quando escrevemos um arquivo, temos total controle sobre o que está acontecendo. Por outro lado, quando o lemos, não sabemos o que esperar. Além de todos os tipos de dados que um arquivo correto pode conter, um programa robusto também deve tratar arquivos inválidos elegantemente. Dessa forma, codificar rotinas de entrada robustas é sempre difícil.

Neste capítulo, veremos como usar Lua para eliminar todo o código para leitura de dados de nossos programas, simplesmente escrevendo os dados em um formato apropriado.

12.1 Arquivos de Dados

Os construtores de tabela proveem uma alternativa interessante para formatos de arquivos. Com um pouco de trabalho extra ao escrever os dados, a leitura torna-se trivial. A técnica é escrever nosso arquivo de dados como um código Lua que, quando executado, constrói os dados dentro do programa. Com construtores de tabela, esses trechos podem se parecer notavelmente com um arquivo de texto comum.