Postagem em destaque

Controle PID de Potência em Corrente Alternada - Arduino e TRIAC - Parte I

Este post é o primeiro de uma série de seis que escrevi tratando de controle de potência e PID (controle proporcional, integral e derivativo...

domingo, 31 de agosto de 2014

Câmera na janela

Estou ajudando alguns alunos lá no Automação no Parque a fazerem uma "casa domótica", que nada mais é do que uma casa comandada pelo celular. Um dos requisitos do projeto é o monitoramento remoto através de câmeras instaladas pela casa. Estamos usando o Raspberry Pi pelo fato do Arduino não conseguir lidar bem com imagens, e o Raspberry tem inclusive uma câmera feita prá ele que já foi usada por aqui em outros projetos.

Começamos a trabalhar no projeto em maio, e na época pesquisamos várias alternativas para "publicar" as imagens da câmera na net. O fato é que, depois de muito apanhar, não conseguimos um resultado satisfatório.

Aí os caras sumiram, foram cuidar de outras coisas como o protótipo da casa etc. Semana passada eles voltaram, e a gente fez a parte relativa ao sensor PIR que inclusive já foi publicada cá no último post. Voltamos então a pesquisar o assunto câmera-net e não é que achamos uma solução perfeita para a nossa necessidade?

Basicamente a gente seguiu o que está escrito aqui. Os caras desenvolveram uma biblioteca específica para se criar um site que publique as imagens captadas pela câmera do Pi em tempo real. E ainda criaram muitas outras features, você pode por exemplo acessar os comandos da câmera e criar efeitos especiais.

Para usar é só seguir os passos do link acima, nem vou colocar aqui um tutorial porque o dos caras tá perfeito e é muito simples.

Tem também uma wiki com a documentação completa da lib dos caras. Em resumo: trabalho de primeira!

Para você acessar a aplicação que fiz, acesse: http://automatobr.noip.me:81/. Se vc prestar bem atenção, vai ver os carros passando pela Dutra cá em São José dos Campos. A câmera está no décimo terceiro andar desse prédio que vc vê aqui.

Obs: se estiver fora do ar é porque está "em manutenção". Vou receber mais dois Raspberry Pi (modelo novo, B+) hoje de tarde, aí vou poder deixar essa plaquinha com a câmera em paz...

Os caras publicaram esse troço no dia do meu aniversário do ano passado. Um presente e tanto...

Abracadabraço,

Mauro Assis

domingo, 24 de agosto de 2014

Sensor PIR de movimento

Ontem no Automação do Parque uma turma que está fazendo um projeto de automação residencial reapareceu. Uma das demandas que tem o projeto deles é um sensor de presença, para funcionar como um alarme. Aí nos dedicamos a entendê-lo e usá-lo a partir do Raspberry. Como eu também tenho um, resolvi usá-lo também num projeto de MQTT que vou escrever mais tarde.

O sensor de presença mais barato e comum é o PIR (Passive InfraRed), ou sensor passivo baseado em infravermelho. O sensor propriamente dito é esse aí:



Dois pinos para alimentação e um para o sinal.

Para usar em projetos normalmente se usa um dispositivo "inteligente", que já vem com um amplificador de sinal e também permite ajuste da sensibilidade e da latência (o que possibilita o sistema parar de dar alarme depois de um tempo se o movimento continua. Fica assim:



Foi um esses daí que a gente usou ontem na brincadeira, e também é muito semelhante ao que eu tenho.

Essa parte branca de plástico é uma lente colocada sobre o sensor da primeira foto, de modo a amplificar o "sinal" (no caso, o calor do corpo) e também aumentar o ângulo de percepção do sensor.

Para aqueles versados no idioma de Sir Mick Jagger aqui tem uma descrição bastante detalhada e interessante sobre o bicho. Aqui, as usual, o negócio é por prá rodar, então vamolá.

Para testar o bicho, primeiro liguei no Arduino. Como sou mais familiar com o bicho e ele é danado de simples e robusto, além de custar muito menos e ser mais fácil de encontrar que o RPi, toda vez que vou testar um sensor novo prefiro usar o Arduino. Depois que funciona aí levo prá outra plataforma.


Acima o circuito como ligado no RPi. Usa-se um resistor de 10k como pull-up. Para entender o papel desse resistor é só clicar.

Para testar no Arduino o circuito é o mesmo só que conecta-se o fio amarelo (saída do sensor) a uma entrada digital do Arduino (dããããã!). Usei o seguinte código:

 i#define pirInput 8  
 void setup()  
 {  
  Serial.begin(9600);  
  pinMode(pirInput,INPUT);  
 }  
 void loop()  
 {  
  int sensor = digitalRead(pirInput);  
  if (sensor == 0)  
  {  
   Serial.println("Movimento");  
  }  
  delay(300);  
 }  

Simples a mais não poder, não?
Basicamente a gente lê o sinal da porta onde está conectado o PIR, no caso a 8 e se for 0 quer dizer que o sensor indica movimento.

Funcionou que foi uma beleza.

No Raspberry Pi

Como sabemos de outros carnavais, o RPi trabalha com 3,3V e o Arduino com 5V. O sensor, segundo me confidenciou o Google, "guenta" de 3 a 5V. Testei no Arduino alimentando o circuito com as duas tensões, e como sói acontecer (ui! essa foi do fundo do baú!) com sensores, ele funcionou melhor com 5V do que com 3V3.

Aí vc pergunta: "Mas e aí, tio, cumé qui faiz? Se a gente plugar ele na porta 5V do RPi não vai dar zica?". Bom... depende. Se a SAÍDA do sensor for mais do que 3V3 a coisa pega, mas vai que a entrada é 5V e a saída é "menas" tensão?

Pelo multímetro vi que, quando o sensor "sente", ou seja, envia sinal de movimento, apesar de estar plugado em 5V a saída é no máximo 3,5. Ou seja, corajoso que sou, tasquei o bicho no 5V e liguei direto na porta. Vc, mais cuidadoso, pode ligar na alimentação 3,3V ou usar um divisor de tensão para abaixar um pouco a tensão de entrada do RPi.

No Pi, em Python:

1:  import RPi.GPIO  
2:  import time  
3:  RPi.GPIO.setmode(RPi.GPIO.BCM)  
4:  RPi.GPIO.setup(24, RPi.GPIO.IN)  
5:  sensor=0  
6:  try:  
7:    while True:  
8:      sensor=RPi.GPIO.input(24)  
9:      if(sensor):  
10:        print "Movimento"  
11:      else:  
12:        print sensor  
13:      time.sleep(1)  
14:
15:  finally:  
16:    print 'Fim'  
17:    RPi.GPIO.cleanup()  

Aqui, na linha 4 a gente define que a porta 24 vai ser de entrada. Na linha 8 a gente lê o valor, se verdadeiro imprime a palavra movimento, semelhante ao que rolou no Arduino.

O que tem de novo é a linha 6 em conjunto com as linhas de 14 em diante. É um recurso que não tem no Arduino, que é o tratamento de exceção. Observe que o programa tem um "loop eterno" (while True, linha 7), ou seja, se a gente deixa rodando ele vai até o Fim dos Tempos. Para parar o bicho dá-se então um Ctrl-C, o que interrompe a aplicação Ptython. Acontece que se a gente faz isso, a porta GPIO fica "pendurada", quer dizer, o Pi fica achando que ela está bloqueada para uso da aplicação que morreu. Ou seja, mesmo que o programa termine com Ctrl-C, temos que rodar a instrução RPi.GPIO.cleanup(), que libera a porta para outro programa que vier atrás, ou esse mesmo executando de novo.

Para isso usa-se o bloco try...finally. O que estiver dentro do bloco try roda de forma "protegida", quer dizer, em caso de erro o programa, em vez do bicho simplesmente abortar a execução, ele executa o bloco definido pelo comando finally. Como o Ctrl-C gera uma condição de erro, o sistema vai sair "elegantemente", liberando a porta para outro uso posterior.

Aqui imagens dos nossos testes no parque:


O sensor exposto...


E aqui ele coberto com a nossa Campânula de Calibração para Sensores PIR (CACASPIR), que impede que o sensor fique sentindo quando a gente não quer.

Abaixo, fotos do Parque ontem. Os meninos à esquerda são alunos de nível médio e estão cá aprendendo Arduino para fazer um trabalho de escola., e os marmanjos à direita estão cuidando da maquete de sua casa domótica.


E por fim, fotos da minha caminhada pela "orla" joseense hoje pela manhã. Para quem não é daqui, São José dos Campos tem o Banhado, que é um ex-banhado ou ex-brejo, já que foi drenado há muito tempo. É uma baixada imensa (uns mil ha) ao lado da praça da matriz (!) que pertence ao município e servirá para algum uso futuro pela cidade. Aqui vc vê a dita, é essa área verde limitada leste pela cidade e a oeste pelo rio Paraíba do Sul.


De longe não parece uma praia?







Bom, e o que isso tem a ver com automação? Nadica, só queria compartilhar com vosotros as belezas matinais joseenses...

domingo, 17 de agosto de 2014

MQTT - O protocolo da IoT (Internet das Coisas) II

Primeiros exemplos de software

Nesse post vamos ver como é fácil trocar mensagens usando-se o MQTT, em diferentes linguagens e sistemas operacionais.

1) O Broker

Para os nossos testes usaremos o broker do Eclipse, que é publicado pelo site iot.eclise.org. É muito fácvil usá-lo, vc não tem que fazer inscrição nem nada, basta acessar o endereço iot.eclipse.org na porta 1883 com um cliente MQTT e pronto. Na realidade é um broker Mosquitto que os caras deixaram "aberto ao público".

Outros clientes MQTT públicos podem ser encontrados aqui.

2) Python no PC

Vamos começar com o Python para aprender como conectar coisas através do MQTT.
Importante: todos os exemplos em Python desse blog são em Python 2.7. Devem funcionar para versões mais recentes.

O que precisamos:

1) Instalar o Python no Windows. Para isso, aqui tem um bom roteiro em português.

2) Instalar o cliente MQTT Python para que esteja disponível para nosso uso. Para isso, siga o roteiro abaixo.  Se vc já tem o pip instalado e funcionando, pode pular pro item "c" abaixo.

   a) Primeiro instale o easy_install. Eu usei essa versão aqui. Depois adicione o easy_install ao seu path, ou então execute-o a partir do diretório onde foi instalado: C:\Python27\Scripts.

   b) Depois você pode instalar o pip, que é uma "casca" em python para o easy_install. Comando:

   c:\python27\Scripts\easy_install pip

   c) Por fim, instale o pacote Paho, que é o client mais popular para MQTT em Python:

   c:\python27\Scripts\pip install paho-mqtt

Agora, ao código:
# -*- coding: utf-8 -*-
import paho.mqtt.client as mqtt

ipBroker = "iot.eclipse.org"
portBroker = 1883

def on_connect(client, userdata, flags, rc):
    print("Connected with result code "+str(rc))
    client.subscribe("$SYS/#")
    
# The callback for when a PUBLISH message is received from the server.
def on_message(client, userdata, msg):
    print(msg.topic+" "+str(msg.payload))

client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message

client.connect(ipBroker,portBroker,60)

client.loop_forever()

Esse código subscreve as mensagens publicadas pelo SYS/#, que é a tag das mensagens do próprio broker.

Essas linhas são as que criam o objecto client, definindo duas callbacks (funções que são chamadas quando ocorrem eventos do MQTT): on_connect, que é chamada após a conexão e a on_message, que é chamada a cada mensagem que é recebida.

client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message

client.connect(ipBroker,portBroker,60)

Observe que colocamos a instrução de subscrição da mensagem dentro do calback on_connect. Isso é feito assim para que, uma vez que a conexão seja perdida, ao ser restabelecida a subscrição será novamente feita.


def on_connect(client, userdata, flags, rc):
    print("Connected with result code "+str(rc))
    client.subscribe("$SYS/#")

Ao executar esse código "de dentro" do Python, vc vai ver algo como:

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
Connected with result code 0
$SYS/broker/version mosquitto version 1.3.2
$SYS/broker/timestamp 2014-07-22 07:11:39-0400
$SYS/broker/changeset 437df4dc8accc0cbf652a2c169c9d8cc85c0f2bf
$SYS/broker/clients/total 13132
$SYS/broker/clients/active 275
$SYS/broker/clients/inactive 12857
$SYS/broker/clients/maximum 13132
$SYS/broker/clients/expired 0
$SYS/broker/messages/received 14083665
$SYS/broker/messages/sent 31839636
$SYS/broker/messages/stored 155234
$SYS/broker/bytes/received 2058300766
$SYS/broker/bytes/sent 2375988666
$SYS/broker/publish/messages/received 4834330
$SYS/broker/publish/messages/sent 21818090
$SYS/broker/publish/messages/dropped 17708425
$SYS/broker/publish/bytes/received 1188558495
$SYS/broker/publish/bytes/sent 8174454185
$SYS/broker/subscriptions/count 20154
$SYS/broker/connection/m2m.cosm-data/state 1
$SYS/broker/connection/zenzium3.zenzium1/state 1
$SYS/broker/connection/zenzium3.m2m/state 1
$SYS/broker/connection/lt022.m2m.eclipse.org/state 0
$SYS/broker/connection/lt022.brigde-to-me/state 0
$SYS/broker/uptime 2247659 seconds
$SYS/broker/retained messages/count 149976
$SYS/broker/heap/current 298899392
$SYS/broker/heap/maximum 455509304
$SYS/broker/load/messages/received/1min 480.04
$SYS/broker/load/messages/received/5min 453.04
$SYS/broker/load/messages/received/15min 446.98
$SYS/broker/load/messages/sent/1min 411.49
$SYS/broker/load/messages/sent/5min 392.83

2) Python no Linux (Raspbian, do Raspberry Pi)

Nesse caso também vc deve instalar o cliente MQTT paho, só que o Python já estará instalado e o pip também, então será só dar o comando abaixo, numa janela do terminal:

   pip install paho-mqtt

Em seguida, se vc executar o mesmíssimo programa acima, obterá os mesmos resultados.

3) C# .Net

Agora vamos ver como subscrever a mesma lista de mensagens no C# .Net. A primeira coisa é instalar o client MQTT no Visual Studio. O exemplo abaixo foi feito no Visual Studio 2013 Express, versão gratuita, então certamente funcionará nas versões mais parrudas do VS.

Para "pegar" a lib, podemos usar  o NuGet de dentro do VS mesmo. Para isso:

       a) Crie uma nova aplicação C# WinForms.

       b) Clique com o botão direito em cima do nome do projeto no Solution Explorer. Selecione a opção Manage NuGets Packages.

       c) Na caixa Search, digite: M2Mqtt. O Manager vai fazer os downloads necessários e também adicionar ao seu projeto as referências às assemblies necessárias, no caso M2Mqtt.

Ao código, então. Fiz um form com quatro "TextBoxes": Um para informar a URL do broker, outro para a porta, um terceiro para informar a tag das mensagens a serem subscritas e um quarto para exibir as mensagens. Um botão inicia o funcionamento:


Aqui, os fontes, como é de lei nesse blog:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using uPLibrary.Networking.M2Mqtt;
using uPLibrary.Networking.M2Mqtt.Messages;

namespace MQTT.Net
{
    
    public partial class Form1 : Form
    {
        MqttClient mqttclient = null;

        public Form1()
        {
            InitializeComponent();
        }

        delegate void SetTextCallback(string text);

        private void SetText(string text)
        {
            if (this.Messages.InvokeRequired)
            {
                SetTextCallback d = new SetTextCallback(SetText);
                this.Invoke(d, new object[] { text });
            }
            else
                Messages.AppendText(text+"\r\n");
        }

        private void Go_Click(object sender, EventArgs e)
        {
            // Create client
            mqttclient = new MqttClient(Broker.Text);
            
            // Set the message receive event
            mqttclient.MqttMsgPublishReceived += 
                client_MqttMsgPublishReceived;

            // Connect to the broker
            string clientId = Guid.NewGuid().ToString();
            mqttclient.Connect(clientId);

            // Subscribe messages
            mqttclient.Subscribe(new string[] { Subscribe.Text }, 
                new byte[] { MqttMsgBase.QOS_LEVEL_EXACTLY_ONCE });
        }

        void client_MqttMsgPublishReceived(object sender, 
            MqttMsgPublishEventArgs e)
        {
            // The MQTT lib engine runs in another tread, so it´s necessary 
            // to do some trick to update Messages.Text property.
            // See SetText above.
            SetText(e.Topic);
        }

    }
}

À exceção do "truquinho" por causa das threads diferentes, nada de complicado, nénão?

Abaixo, uma imagem dos três subscribers rodando simultaneamente, recebendo as mensagens do $SYS/# no broker do eclipse.org. A tela em azul mais à direita é a aplicação Python rodando no Windows, a azul mais ao fundo à esquerda tá rodando no Raspberry via Terminal Services. E a tela à frente é a .Net C#.

CQD, molezinha.




















No próximo post vamos fazer um aplicação completa envolvendo Arduino e também estressar um pouco o servidor com mensagens rápidas.

Abracadabraço, até o próximo post.

terça-feira, 12 de agosto de 2014

MQTT - O protocolo da IoT (Internet das Coisas) I

Srs frequentadores deste,

Nos próximos posts vou fazer uma série sobre MQTT. A ideia é fazer como na série que fiz sobre PID, que até hoje são dos posts mais acessados desse blog. Seguiremos as mesmas premissas, a saber:

- Rigor na teoria, abordando com precisão os conceitos envolvidos.

- Apesar disso, uso de uma linguagem mais coloquial, facilitando o entendimento.

- Abuso de exemplos práticos, relacionando o MQTT com outros assuntos.

Boralá?

O que é MQTT

MQTT "stands for" (como dizem os conterrâneos do Obama)  Message Queue Telemetry Transport, ou Fila de Mensagem para Transporte de Telemetria.  É um protocolo (mais um!) do tipo publicar/subscrever, o que significa que "algo" publica mensagens em algum lugar e outro "algo" subscreve (assina, no sentido de assinatura de jornal/revista), recebendo as mensagens publicadas. Nesse tipo de protocolo não há comunicação direta entre o emissor e o receptor da mensagem, ou seja, não é "peer-to-peer", ponto a ponto. Tudo passa por um servidor, aplicativo que recebe as mensagens publicadas e as entrega aos subscritores correspondentes e é chamado broker (intermediário ou corretor, em português), por razões óbvias.

Obs: uma máquina pode ter instalado o servidor MQTT e também subscrever/publicar mensagens, mas nesse caso um aplicativo, mesmo rodando no servidor, terá que subscrever mensagens se quiser vê-las, "passando" assim pelo aplicativo broker.

Características do MQTT

- Simplicidade de codificação, o que faz com que o código fique pequeno, podendo rodar até num Arduino, embora nesse caso com alguma dificuldade, como veremos.

- Sem muito overhead, quer dizer, as mensagens não tem muita coisa além do que os dados propriamente ditos, o que favorece o uso de redes com pouca velocidade de transmissão de dados. Um exemplo de "protocolo" que gera muito overhead é o XML, que permite a estruturação da informação enviada mas exige muito texto formatando essas informações.

- O protocolo é de domínio público ou seja, pode ser implementado por quem quiser.

- Existem vários brokers que vc pode usar de graça, e também outros que vc pode instalar no seu servidor e fazer dele um broker. Vamos ver pelo menos um deles mais à frente, o Mosquitto.

Porque é interessante usar um protocolo como MQTT em IoT?

Quando vamos fazer com que equipamentos se comuniquem e atuem cooperativamente, um protocolo de comunicação tem que ser usado, para que um "entenda" o que o outro estiver "dizendo". Você pode criar o seu próprio protocolo, o que implica em escrever algum código (programas) que traduza as demandas do processo (o que deve ser feito em conjunto, a tarefa em si) em comandos padronizados. Depois vc deve decidir qual a camada pela qual esses dados deverão ser transportados e usá-la, definindo também parâmetros para sua configuração. Um exemplo:

Se vc for fazer comunicação serial, deve definir a velocidade em bauds (bits/s), se tem paridade ou não etc.

Já se vc usa algo como o MQTT não precisa se preocupar com os detalhes da comunicação em si, já que o protocolo já está definido.

Outra vantagem muito importante do uso do MQTT é a padronização do hardware, quer dizer, toda a comunicação é feita usando-se rede cabeada ou wifi. Cada vez mais as "coisas" possuem portas para esse tipo de de conexão, por exemplo, quase todos os modelos de TV hoje vêm com esse tipo de acesso.

Usando como base de comparação também a comunicação serial, até por ser ela talvez a mais usada para conectar equipamentos:

Existem alguns "padrões" de hardware para comunicação serial: RS-232, RS-485, TTL e outros. Acontece que esses padrões não são muito claros, o que gera confusão. O RS-232 pode usar tensões de +5/-5V a +24/-24V, enquanto que o TTL usa somente tensões positivas até 5V. Ou seja, sempre que você for conectar equipamentos com o protocolo serial, terá que ser considerado algum circuito para conectar os dois equipamentos. Esse circuito pode ser simples, por exemplo dois resistores para ajustar tensões diferentes entre dispositivos TTL (Arduino e Raspberry Pi entram nesse grupo) até circuito integrado e capacitores caso seja necessário acoplar RS-232 com TTL.


Acima, imagem de um circuito de acoplamento entre RS-232 (plug metálico à direita, chamado DB9) e TTL, no caso os fios verde e azul que fazem a conexão com o Raspberry Pi.

Se vc usa MQTT e os equipamentos tem acesso à internet (como os dois acima) nada disso é necessário.

O MQTT é também adequado para IoT pelo fato de ser simples, podendo ser implementado em equipamentos com pouco poder de processamento.

Outra vantagem é que ele é baseado em TPC/IP, que é o protocolo de rede da internet, ou seja, os equipamentos podem estar na mesma sala ou em países diferentes.

Por fim o MQTT possui camadas de segurança da informação que fazem com que, caso necessário, possa ser adotada uma comunicação com níveis de segurança da informação bastante adequada. Isso é muito importante já que é virtualmente impossível determinar por onde exatamente circula ou quem está tendo acesso a uma mensagem via web.

Quem usa

Existem muitos projetos baseados em MQTT. Aqui tem uma pequena lista, que curiosamente não inclui o Facebook Messenger que, segundo o próprio povo do Facebook, "roda" em MQTT. É legal identificar no texto que o povo do Facebook considera as mesmas vantagens a respeito do MQTT, que são as óbvias descritas acima, como responsáveis pela escolha do protocolo por eles.

Bom, aí foi um papo a respeito do MQTT. No próximo post, vamos praticar um pouco.

segunda-feira, 4 de agosto de 2014

Comunicação Serial no Arduino - dica

Nesse blog tem coisa de 90 posts, a grande maioria deles tratando de Arduino. Já são mais de três anos trabalhando com o Arduino e a gente ainda tem a aprender... Estou trabalhando de consultor na área de inovação de um cliente. Uma das demandas que apareceu ultimamente foi acessar através de comunicação serial um equipamento. Acontece que a saída do equipamento é RS-232, e os processadores e computadores trabalham com TTL, então torna-se necessário converter os sinais entre eles.

Resolvi testar o circuito que montei para isso no Arduino. Precisava então ver os dados que estariam sendo recebidos e também enviar dados. Quando fui fazer um programa para ler dados de uma serial e enviar para a serial default do Arduino o chefe, que tem a manha, me disse: "é só fazer um programa que não faça nada e enviar para o Arduino. Quando isso acontece o Arduino vira uma "ponte serial", lendo dados da porta e replicando o que chega na tela de terminal. O programa então fica assim:

void setup()
{
}

void loop{}
{
}

Para testar o circuito foi só conectar o TX com RX no lado RS-232 e ligar o RX/TX do lado TTL ás portas 0 e 1 digitais do Arduino. Ao digitar dados e enviar para o Arduino na janela de comunicação serial o dado digitado é "ecoado" de volta, ou seja, aparece na janela do terminal. Você pode testar isso em qualquer velocidade até o máximo que o Arduino aceita, 115,200 kbps.

Interessante, não?

domingo, 3 de agosto de 2014

Trinket, o menor Arduino-like II

Para testar a nossa plaquinha (depois de rodar o Blink, claro), resolvi acionar um servo.

A lib de servo que vem com o Arduino não rola, porque o ATtiny não tem timer de 16 bits. Para "tocar" um servo precisamos então de uma outra lib, compatível. O povo da Adafruit fez uma, que vc pode baixar daqui. Essa lib tem um pequeno inconveniente: vc tem que chamar a rotina de refresh dela a intervalos de no máximo 20 milissegundos. Vamos analisar cá um exemplo. É o que vem com a lib, simplificado:

#include <Adafruit_SoftServo.h> 
#define SERVO1PIN 0   

Adafruit_SoftServo myServo1;

void setup() {
// Seta a rotina de interrupção (ver depois do loop)
  OCR0A = 0xAF;   
  TIMSK |= _BV(OCIE0A);
  myServo1.attach(SERVO1PIN);
}

void loop()  {
  myServo1.write(0);
  delay(2000);       
  myServo1.write(90);
  delay(2000);       
  myServo1.write(180);
  delay(2000);       
}

// Essa rotina é chamada de 2 em 2ms, então ajustamos para chamá-la a cada 20ms.

SIGNAL(TIMER0_COMPA_vect) {
  counter += 2; 
  if (counter >= 20) {
    counter = 0;
    myServo1.refresh();
    digitalWrite(1,HIGH);
  }
}

Ao rodar o programa, o servo alterna entre as três posições: 0, 90 e 180 graus.

Mole,. não? Nem vou fazer filminho... :)

A ideia foi mostrar que a plaquinha não faz feio mesmo em tarefas de automação. Dá prá controlar pelo menos mais um servo, simultãneamente.

Trinket, o menor Arduino-like I


Dia desses comprei três Trinkets na Amazon, mas no fim só chegaram dois, :(. Dei um pro Euclas e fui brincar com o meu. Eis aí as primeiras impressões.

O hardware

Essencialmente o Trinke é uma plaquinha baseada no ATTiny85, processador de 8Kb de memória flash (para programas), 512 bytes EEPROM e 512 bytes SRAM. Com o bootloader (programa que recebe os programas que mandamos pela serial os "roda" no processador) sobra-nos pouco mais de 5k para trabalhar. Não dá para desenvolver nenhum Excel, mas dá para fazer aplicativos simples de automação residencial ou mesmo pequenos robôs. Vou fazer alguns para postar por aqui.

Aqui, a plaquinha mais de perto:


Dá prá ver aqui as características da bichinha. Existem dois modelos: 5V e 3V3, me arrependi de não tem comprada nenhuma de 3V3 para conectar direto do Raspberry.

- Conector mini-USB para conexão ao PC e também para alimentação. Isso é muito legal, porque dá prá programar diretamente no PC e enviar o programa sem ter que usar nenhum outro hardware para isso.

- GPIO (pinos de entrada/saída de dados), numerados de #1 a #4.

- Conexão de bateria externa. Pode-se ligar até 16V na bichinha.

- Botão reset.

- Conexão para botão reset externo.

- Furos para fixação

"Tudo isso" faz dessa plaquinha uma bela alternativa para projetos onde a minitaturização é essencial. Também o consumo de energia é menor, o que favorece o uso de baterias menores e/ou a durabilidade delas.

Coonfigurando e programando

Segui os procedimentos indicados aqui para colocar ele prá funcionar através da IDE do Arduino. Segui o roteiro chamado no texto de The Slow Way, que visa reconfigurar a IDE do Arduino para trabalhar também com o Trinket. Após as alterações (bem fáceis), fui testar e... nada.

Primeiro a IDE não reconheceu o dispositivo. Pesquisando, vi que ela não trabalha com USB 3.0, só com USB 2 ou 1. Como transformar a USB do micro em uma versão anterior? O jeito que dei foi arrumar um desses multiplicadores de portas USB mais velhinho e usá-lo. Ele fez a conversão, e o Trinket apareceu na lista de dispositivos conectados.

Veja o processador da plaquinha, o segundo da lista. Também é possível dar overclock de 16 MHz
Depois não apareceu a porta serial para que eu a selecionasse. Pesquisa dali e daqui, descobri que a porta não aparece mesmo na lista, mas é só selecionar a plaquinha correta na lista (menu Tools\Board, placa Trinket 8 MHz) e o bichinho funciona que é uma beleza.

Para testar, podemos rodar o velho blink. A única alteração é que a porta conectada ao LED é a porta 1, então temos que alterar a variável led do programa para 1.

Na hora de fazer o upload é um pouquinho diferente:

- Quando vc liga a plaquinha no Arduino ela inicialmente fica piscando por uns 10s. Nesse modo ela está pronta para receber o programa via USB. Após esse período ela começa a rodar o programa que está nela, e não é possível fazer o upload de uma nova versão. Para habilitar de novo o envio, deve-se apertar o reset de novo para um novo ciclo de upload.

Bom, é isso. No próximo post, um exemplo com ela.