Home › Category Archives › Informação

Como programar um ESP8266 como se fosse um Arduino.

Do jeito que sai da fábrica o módulo ESP8266 precisa ser usado através de comandos AT e você precisa de um outro microcontrolador (um Arduino, por exemplo) para fazer qualquer coisa útil.  Muitos viram isso como um desperdício de capacidade já que qualquer módulo ESP8266 tem mais RAM, flash e roda com um clock mais rápido que o Arduino Mega. Então meses depois do lançamento vários grupos começaram a trabalhar em métodos para usar o o ESP8266 de forma independente, mas o método que eu achei mais impressionante permite que que você use o ESP8266 como se fosse um Arduino, com o mesmo IDE e até mesmo boa parte das bibliotecas existentes. Não é o método mais rápido porque a cada vez que você faz o upload do programa, está recompilando e gravando todo o firmware, mas é o mais simples de configurar e usar.

Procedimento simplificado (o completo pode ser visto aqui)

  • Baixe e instale uma versão recente do IDE Arduino. Todas as versões a partir da 1.6 suportam a definição de novas placas. Se quiser fazer uma versão portável, leia esse meu outro post;
  • Nas preferências, adicione “http://arduino.esp8266.com/stable/package_esp8266com_index.json” em “Additional Board Manager URLs “;

arduino_ide_preferences_BoardsManager_automalabs.com.br

  • Abra o Boards Manager. Uma lista de boards disponíveis irá ser baixada da internet. Procure pela board ESP8266 (geralmente aparece no fim da lista). Clique, escolha a versão (hoje existem duas) e selecione “install”.  O download tem hoje pelo menos 150MB;arduino_ide_BoardsManager_automalabs.com.br
  • Selecione como placa o “Generic ESP8266 Module”;

arduino_ide_boards_esp8266_automalabs.com.br

A Sparkfun lista algumas coisas que você precisa saber ao programar. Relação entre pinouts, diferenças entre bibliotecas, a necessidade de “yielding”, etc.

Tenha em mente que programas feitos especificamente para o ESP8266 sequer passam na verificação se a board escolhida não for o ESP8266. Acusarão  erro de falta de bibliotecas, mesmo você sabendo que elas estão instaladas.

Diferenças entre as versões 1.6.x e 1.0.x do Arduino IDE que podem criar problemas.

  • Por default a versão 1.6.x salva automaticamente os sketches ao verificar ou fazer upload. Se você estava acostumado a fazer pequenas mudanças em um sketch salvo e fazer upload para testar e só salvar se/quando desse certo, no futuro vai descobrir que o código não funciona mais no cenário original e provavelmente não vai saber a razão. O editor salvou suas modificações experimentais sem aviso. Isso pode ser desligado nas preferências;
  • Até versão 1.0.x você podia tranqüilamente ter várias versões do IDE com configurações diferentes sem conflitos, descompactando o ZIP em diretórios diferentes. Isso ainda permitia que sua instalação fosse verdadeiramente portável. A partir da versão 1.5.x o Arduino passou a guardar/procurar suas preferências no perfil do usuário corrente, em %appdata%\Local\Arduino15\. Então uma mudança feita em uma cópia se propaga para outras cópias. Isso é ainda pior se você estiver usando o ESP8266 como board, porque tudo é instalado no perfil do usuário em vez de ser instalado no diretório do Arduino. Mova/copie sua instalação para outro computador e ela não funciona mais. Para contornar isso é preciso, logo depois de descompactar o ZIP, criar um diretório chamado “Portable” no diretório do editor. Ao executar o programa ele detectará a presença do diretório como uma instrução para não usar o perfil do usuário e guardará tudo nele.
  • Em algum ponto entre a versão 1.6.5 e a versão 1.6.7 o compilador passou a ser mais exigente com relação à declaração de funções. Código que compilava perfeitamente pode começar a dar um monte de erros do tipo “undefined”. Verifique se a função está sendo definida depois de ser chamada. Se estiver, isso é resolvido movendo a função para um ponto anterior ao ponto em que ela é chamada. O resultado é que “loop” e “setup” agora dão menos problemas se forem movidos para o final do sketch. Esse é o comportamento “correto” do C++. As versões anteriores do IDE é que estavam sendo “boazinhas” com você.

Receptores de controle remoto IR : Problemas para decodificar comandos.

Mantenha o receptor protegido da iluminação ambiente

Luz incidindo sobre o receptor, mesmo que não seja modulada, pode saturar (“cegar”) o sensor e dificultar sua capacidade de reconhecer outras fontes de luz. É por isso que receptores de aparelhos comerciais ficam dentro dos aparelhos, recuados.

Iluminação fluorescente é especialmente complicada

Muitos reatores eletrônicos para esse tipo de lâmpada operam numa freqüência muito próxima dos controles remotos comerciais e por isso os receptores podem ficar cegos por elas com muito menos iluminação. Isso também vale para TVs LCD: o backlight opera pelo mesmo principio e um receptor voltado para uma TV pode ficar cego.

Problemas com comandos de 36 bits

Se você estiver encontrando uma incomum dificuldade para decodificar remotos que usam comandos 36 bits (XBOX, GVT, OI) , experimente usar outro modelo de receptor.  Eu tive sucesso total usando o TSOP58238 onde um outro modelo mais antigo não decodificava comando algum. O sintoma é que a biblioteca “acha” que o comando é de 32 bits, mesmo sendo uma versão que reconhece comandos de 36 bits, então você pode demorar a perceber que o problema está no comprimento do código.

Controles de ar condicionado são mais complicados

O controle de ar condicionado pode ser muito diferente do controle IR tradicional. Geralmente o controle guarda o estado atual do aparelho e cada vez que você aperta um botão, TODO o estado é retransmitido. Cada parâmetro é um bit ou conjunto de bits na string de transmissão.

Com exceção, provavelmente, dos comandos POWER ON e POWER OFF.

Então, se você quiser transmitir um determinado estado completo, isso é fácil. Mas se quiser apenas aumentar ou diminuir a temperatura sem mexer nas outras configurações feitas, vai precisar entender o protocolo do aparelho e construir os comandos através de manipulação de bits.

Os que eu estudei são assim. Podem haver exceções, mas não vejo como o controle remoto poderia se manter sincronizado com o estado do aparelho, a não ser que este aceite um segundo protocolo, só para comandos discretos.

Drivers para chip USB – serial UART CH340, CH340G, CH341

O CH340 / CH341 é um chip USB serial chinês que vem substituindo com sucesso os tradicionais chips da Silabs (CP2101, CP2104) e Prolific (PL2303) em diversos produtos e está presente em diversos clones do Arduino fabricados na China.

Direto do fabricante chinês. O link é para a versão Windows, mas na página você tem links para versões MAC, Linux e até Android

 

Fique de olho no tamanho do arquivo de log do arduino

Em certas circunstâncias, notadamente se você desplugar a placa e mantiver o IDE aberto, o arquivo de log criado pelo arduino pode ficar gigantesco, com dezenas de gigabytes, consumindo todo o seu espaço em disco disponível e possivelmente criando um problema de desempenho na máquina. E quando você finalmente fechar e reabrir o IDE outro arquivo de log será inicializado, mas o anterior continuará ocupando espaço em disco.

Os arquivos de log ficam no diretório TEMP do usuário. No Windows 8 isso fica em \Users\<nome do usuário>\AppData\Local\Temp em diretórios que começam com o nome “console”.

Esse problema já foi reportado como bug há anos e ainda hoje, na versão 1.05, ele persiste.

Eu tenho problemas freqüentes com isso porque quando estou trabalhando com Arduino eu desconecto e reconecto os cabos USB sem dar atenção ao IDE. Como meu espaço na partição C: é limitado, em poucas horas o Windows não tem mais espaço livre para usar por culpa do IDE Arduino.

Receptores de controle remoto infravermelho – Cuidados com alimentação

Vários fabricantes de receptores IR recomendam em seus datasheets algo assim (exemplo do datasheet do Everlight IRM-8601):

InfraredReceiver_LowPassFilter_Example_automalabs.com.brNote o resistor de 47R e o capacitor de 47uF. Eles formam um filtro “passa-baixas”* cuja função é impedir que interferência de alta freqüência que venha pela alimentação chegue ao sensor. Essa interferência tanto pode ocorrer “naturalmente” pelo uso de uma fonte chaveada ruidosa quanto ser inserida pelo seu próprio projeto à medida que você insere componentes. Você pode até fazer o seu projeto funcionar normalmente em bancada sem o filtro, mas o risco de que ele acabe funcionando erraticamente depois não vale a economia dos componentes.

(*) Um filtro passa-baixas é o filtro que deixa passar todas as frequências abaixo da frequência de corte e atenua todas as frequências acima.

O filtro precisa estar tão perto do receptor IR quanto possível.

Já o resistor >10K entre VCC e a saída é opcional mesmo.

Este outro exemplo vem do datasheet do Vishay TSOP 1738:

InfraredReceiver_LowPassFilter_ExampleVishay_automalabs.com.br

Este outro do mesmo datasheet, em uma revisão mais recente (rev10):

InfraredReceiver_LowPassFilter_ExampleVishayTSOP17_rev10_automalabs.com.br

E este outro é do Vishay TSOP582:

InfraredReceiver_LowPassFilter_ExampleVishayTSOP582_automalabs.com.br

Valores de resistor e capacitor são diferentes, mas o resultado da maioria é equivalente. Se você usar um calculador de filtro passa baixas verá que o primeiro exemplo (do IRM) tem uma frequência de corte de 72.05Hz, o segundo de 102.61Hz e o terceiro de 338.63Hz. A diferença entre eles é irrelevante porque estão bem abaixo dos vários kHz que seriam um problema. Já o quarto exemplo dá uma frequência de corte (“typical values”) de 15915.49HZ, o que parece estranho. Meu conselho é que siga a recomendação do datasheet do seu receptor específico ou, na falta de um, use um dos três primeiros exemplos.

Arduino Mega 2560 reconhecido como “%mega2560.name%”

Esse problema não é do hardware. É provocado por um erro nas distribuições Windows do Arduino 1.04 e 1.05 que estão fornecendo o arquivo de definição de driver “arduino.inf” incompleto. O problema pode ser corrigido se ao instalar o Arduino Mega e o Windows pedir os drivers, você apontar para o diretório drivers das versões anteriores do Arduino ou (não testado ainda) se você incluir a seguinte linha na seção [Strings] de arduino.inf:

mega2560.name=”Arduino Mega 2560″

A instalação como “%mega2560.name%” explica-se porque a seguinte linha na seção [DeviceList] está “orfã” (sem correspondente na seção [Strings]):

%mega2560.name%=DriverInstall, USB\VID_2341&PID_0010

Sketches que usem a biblioteca NewsoftSerial podem não funcionar no Mega

O problema não é na biblioteca, mas numa diferença que existe entre o Arduino UNO e o Mega que limita em que pinos NewSoftSerial pode receber dados. Segudo o que é explicado neste fórum, esses pinos são:

10, 11, 12, 13,
50, 51, 52, 53,
62, 63, 64, 65, 66, 67, 68, 69

Mas a biblioteca pode transmitir em qualquer pino.

Como a maioria esmagadora dos exemplos que usam NewsoftSerial foram feitos para o UNO (quem usa Mega geralmente não precisa de portas virtuais), é quase certo que usem os pinos abaixo de 10 e assim não vão funcionar no Mega. Isso inclui exemplos de uso para GPS, GPRS, bluetooth…

Se você tem um Mega e não precisa de mais que as quatro portas seriais físicas, eu recomendo que você modifique os exemplos para que usem as portas físicas e não a biblioteca NewSoftSerial (comece apagando a linha #include <SoftwareSerial.h>). Isso economizará espaço na sua flash e dará mais velocidade ao seu programa, porque a criação e uso de uma porta serial virtual tem um impacto no processamento.

Mensagem “Verification error, content mismatch” ao tentar gravar um sketch

Se isso acontecer com você, experimente gravar novamente o bootloader. Eu testei e o problema foi resolvido imediatamente.

Diferenças entre as diversas versões do Arduino

Em poder de processamento um Arduino UNO e um Mega2560 não são muito diferentes. Ambos rodam com o mesmo clock de 16Mhz. Porém além da quantidade de I/O existem duas diferenças significativas:

  • O Mega tem uma flash muito maior, que fará diferença se seus sketches forem grandes. Porém esse é um problema menor porque a limitada quantidade de I/O do UNO difiilmente vai permitir que seu sketch cresça até um ponto que exceda os 32kB do UNO;
  • O Mega tem 4x a quantidade de RAM, o que faz diferença mesmo em projetos muito pequenos, dependendo do que você precisa fazer. Por exemplo, em um projeto que envolva criar um webserver os 2k de RAM do UNO podem atrapalhar bastante a sua criatividade. E um projeto que envolva emular os sinais de um controle remoto de TV você pode ficar impedido de ter todos os botões armazenados em variáveis ao mesmo tempo. Por exemplo, digamos que cada botão requeira uma matriz de 32 bytes (isso é normal). Um único remoto com 20 botões iria requerer 640 bytes da preciosa RAM. Você ainda pode usar um UNO em um projeto desse tipo, mas deve evitar querer controlar todas as funções de todos os aparelhos do seu rack a menos que encontre um meio que use menos RAM.

Esta tabela de de arduino-tutorials ajuda muito como referência das diferenças físicas entre as placas.

arduino-board-comparison-chart

Do ponto de vista educacional existe ainda algumas diferença que considero significativas:

  • um UNO por usar um uC DIP soquetado pode ser consertado com muito mais facilidade e mais barato que um Mega. Então se existe a possibilidade de que erros catastróficos sejam cometidos, como por exemplo ligar 12V em um dos pinos de I/O, um UNO representa uma melhor escolha que um Mega;
  • A maioria esmagadora dos exemplos que você encontra na Internet são feitos para o Uno mas existem ligeiras diferenças entre Uno e Mega que podem fazer muitos desses exemplos não funcionarem no Mega sem algumas modificações. Por exemplo, temos os problemas com a biblioteca NewsoftSerial e a diferença na localização dos pinos de i2C.