Bom, não foi possível cumprir com tudo que foi proposto ao longo da série, bom é possível, só não vai dar agora. E também alguns desejos fugiriam muito da proposta.
Acredito que optar por usar Arduino na Agronomia não é simplesmente para aprender detalhes de lógica de programação, linguagem C, códigos lindos e muitas funções. Ele é apenas uma ferramenta para alcançar um objetivo agronômico. Em um estudo que o arduino foi aplicado ele não é o foco, nos resultados finais não importa o quão lindo ficou seu código ou quantas animações seu display mostra, o que importa é o dado agronômico, a importância do arduino é a mesma da enxada, esta nem citadas nos arquivos, uma simples ferramenta para chegar onde se deseja.
Eu não teria como obter dados reais para analisar depois, pois o tempo aqui não está colaborando nem um pouco para um estudo desse, baixa temperatura, muita nebulosidade e vento, qual o cenário atual seria o oposto. Além de que a greve dos caminhoneiros impossibilita a chegada de novos materiais, como o buzzer. As novas modificações não adicionam vantagens reais ao datalogger, pois juntar em uma matriz as variáveis reduz o código, mas não traz facilidade na implementação. Colocar efeitos na OLED é muito legal, mas não vai fazer diferença no dado final, que é o que importa, sendo que animações demandam tempo.
Então o intuito do blog é ser uma grande biblioteca de partes de códigos sempre com o intuito agro. O objetivo é o seguinte:
Suponha que você precise armazenar em um SD a temperatura de uma estufa, isso vai ocorrer a cada duas horas. Ao invés de programar todo o código, resolver os problemas basta vir aqui no blog, copiar o código de SD em datalogger e o código do DHT22. Juntar os dois e pronto. Pois o que importa não é desenvolver o código e sim só fazer a ferramenta.
Desta forma acredito que a série conseguiu atingir seus objetivos, e os códigos gerados já podem ser usados para a construção de um datalogger, seja lá o que ele vai armazenar. Assim temos já vários códigos que bastam copiar, colar e customizar para ter uma nova ferramenta em menos de vinte minutos, e com essa série aprendemos muito também, cito alguns exemplos:
- Como escolher a plataforma de desenvolvimento para a sua ferramenta
- Determinar quais os recursos do nosso datalogger
- Escolher os sensores e atuadores da nossa ferramenta
- Como determinar que o hardware escolhido não foi o adequado
- Solucionar problemas decorrentes
- Como fazer verificações de SD
- Escolher como lidar com o nosso intervalo
- Millis contra delay, seus uso de problemas em datalogger
- Como verificar e trabalhar com tamanhos de arquivos em SD ao nosso favor
- Uso de LDR para capturar variáveis ambientais, aplicações, limitações e uso
- Trabalhando com OLED, posicionamento de texto, exibição de variáveis e imagens
- Como trabalhar com o DHT22
- Como trabalhar com diversos DS18B20
E acredito que houveram mais conhecimentos documentados ao longo da série, assim vou adicionando os demais posts cujo conhecimento ficaram embutidos no código, facilitando assim encontrar os códigos no futuro. Alguns conhecimentos já foram documentados, como verificação de arquivos, uso de millis e uso de LDR.
Nessa versão que eu chamo de V1.0 eu apenas corrigi o bug que havia na A0.3, em que a verificação no OLED era apenas se houve gravação, mas indicava ser se o arquivo abrir e se houve a gravação. Deixei apenas uma indicação: se houve a gravação, pois no final apenas ela importa.
Não vi muito sentido em colocar a ligação dos fios, pois é basicamente VCC e GND, além dos fios padrão de protocolo SPI e I2C. Os fios diferentes são apenas os de dados, que estão no cabeçalho do código e a seguir o download do código: clique aqui para baixar o código.
Nenhum comentário:
Postar um comentário