o está executando.
Isto ocorre porque vc está usando recursos que consomem RAM em quantidade considerável para um Arduino UNO. Veja o resultado quando seu código original é compilado:
(clique na figura para "zoom")
Mesmo assim existe uma chance de que alguma otimização possa resolver seu problema, pelo menos no atual estágio do seu código. Quando esta otimização é feita, veja o resultado do uso de RAM:
(clique na figura para "zoom")
A otimização em questão se refere a não usar RAM para a alocação de "C strings". Isto pode ser feita em alguns pontos do seu código. Veja alguns exemplos para seu código:
onde está: Serial.println("Inicializando cartao MicroSD...");
substitua por: Serial.println( F("Inicializando cartao MicroSD...") );
--------------------------------------------
onde está: client.println("HTTP/1.1 200 OK");
substitua por: client.println( F("HTTP/1.1 200 OK") );
--------------------------------------------
onde está: if (!SD.exists("index.htm") )
substitua por: if (!SD.exists( F("index.htm") ) )
--------------------------------------------
onde está: novoCliente.println("%");
substitua por: novoCliente.println('%');
--------------------------------------------
Mas veja que nem em todo ponto isto pode ser feito. Por exemplo:
onde está: if (StrContains(HTTP_req, "ajax_LerDados"))
não é possível aplicar a otimização, por a função "StrContains" é uma função "primitiva" que não tem um overload que permita o uso da Macro "F()". Mas isto é possível de ser feito de outra forma (criando uma função intermediária), e é bem simples, caso seja necessário.
Importante: seu Sistema está bem próximo ao limite de Memória para um Arduino UNO. Então se vc pretende em algum momento posterior aumentar a funcionalidade do seu código, aconselho que vc mude a placa base. Caso o custo não seja uma limitante para vc, o caminho mais simples seria usar o Arduino Mega, onde vc não terá estes limitantes de Memória. Mas se na sua aplicação vc tiver WiFi disponível, o melhor seria migrar para um ESP32 ou ESP8266, pois o custo seria bem mais baixo que o Mega, e teria Memória suficiente para sua aplicação.
O seu código original, com as otimizações, está aqui: "ajuda_I2C_LCD_01.zip"
Espero ter ajudado.
Abrçs,
Elcids…
Adicionado por Elcids Chagas ao 20:11 em 7 julho 2021
les, sejam as mais sofisticadas, pra nós são todas importantes).
Alguns comentários sobre meu último post, onde descrevi o problema que vc estava confrontando:
1) mencionei que o GPIO2 estando em "0", como acabava ocorrendo no seu design durante o BOOT do ESP, força o "Modo "UART" ser iniciado pelo ESP (o modo de gravação do código, que todo mundo usa). Na verdade para entrar neste modo, a combinação dos GPIOs é outra, conforme pode ser vista no meu primeiro post (a tal "Tabela 3"). Então o que faz o ESP "travar" quando o GPIO2 está em "0" durante o BOOT ? a resposta pra isso está na tabela a seguir:
Como se pode observar, para o ESP01, quando o GPIO2 está em "0" durante o BOOT, resulta em uma combinação que não é considerada válida. Obviamente, que algo deve ocorrer nessa situação, mas não é divulgado pelo Fabricante, pois provavelmente é reservado para situações de testes na Linha de Produção da Fábrica. Claro que se você gastar horas e horas analisando o código nativo residente do ESP8266, poderá descobrir, mas acho que não vale a pena né?
Também, note que para o ESP01, apenas as 4 primeiras linhas da Tabela são aplicáveis, pois esta placa tem o GPIO15 do ESP8266 ligado a 0V (GND).
E a Tabela pode ser usada para o também popular ESP12, e como este tem o GPIO15 "livre", então todas as combinações se aplicam a essa placa.
Essa Tabela e outras informações significativas, podem ser encontradas neste link: ESP8266 Arduino Core
2) reforço meu conselho de usar 5V para alimentar o Relé, pois se você olhar o datasheet que está no site do Robocore (é fabricado pela Metaltex), vai ver que a tensão mínima da Bobina que é garantido acionar os contatos, é de 3,5V. Se vc alimentar a Bobina com 3,3V, eventualmente um ou outro Relé do mesmo modelo, irá falhar no acionamento, pois você estaria no limiar da tensão mínima de acionamento (na verdade já abaixo desse limiar). Também se acionado com 3,3V, uma pequena pancada no Relé poderá abrir os contatos (e talvez não feche novamente), pois a força do campo magnético criado pela corrente na Bobina (e que aciona os contatos) não será tão forte como em 5V. Além disso, 5V é a tensão nominal desse modelo de Relé.
3) Sua plaquinha Adaptadora para o ESP01 (a da Robocore), possui um regulador LDO na mesma. Isto permite você alimentar o ESP01 seguramente por ela, pois a saída desse LDO é de 3,3V. Outro ponto: o LDO exige uma tensão mínima de entrada maior que a tensão de saída (os 3,3V). Então a plaquinha adaptadora não deve ser alimentada com exatos 3,3V (caso vc a alimente com essa tensão, o LDO não "terá força" para suprir a necessidade de corrente do ESP01, e hora ou outra este poderá falhar).
Finalizando, alguns comentários sobre o código:
1) procure usar a técnica que mostrei, usando os defines para os números dos pinos, e usando os nomes funcionais para os pinos no restante do código (como por exemplo o "pino_Rele" e o "pino_Pisca"), isso certamente deixará seu código mais claro e fácil de trabalhar.
2) Sobre as sentenças lógicas para as decisões de acionamento do Relé, a partir da Hora atual, e dos valores "Ativa" e "Desativa", veja as figuras que preparei a seguir:
e
Bem estas duas últimas figuras, me poupam palavras (ufa!!!) para descrever.
Pessoal, há alguns meses atrás, levantei os esquemáticos do ESP01 e do ESP12, o mais confiável que pude, a partir de diversas referências (em sites e do próprio fabricante), e inclusive medindo alguns pontos nas próprias placas.
Para o ESP01, encontrei duas versões bem solidificadas no mercado, que chamei de "revisão 1" e "revisão 2". Para o ESP12, desenhei apenas uma revisão. Todas os três esquemáticos estou disponibilizando no anexo no final do post.
Mas pra "enfeitar o pavão", seguem os prints para a "rev 2" do ESP01, e para o ESP12:
Luiz, caso tenha algo que possamos colaborar, estaremos à disposição.
Abraços.
Elcids
…
Adicionado por Elcids Chagas ao 20:54 em 22 maio 2018
mo 5V ou 12V por exemplo). E sobre isso, falarei mais à frente (uso de um “driver” simples).
Sobre vc ter usado o TIP122 inicialmente, veja que as características de Potência são parecidas com as do TIP41, e portanto vc também estava forçando a junção Base-Emissor com correntes um tanto altas. Se a junção Base-Emissor é danificada, então o Transistor não é mais confiável, pois não irá se comportar como esperado.
Sobre a aquisição do MOSFET, verifique o famoso site de compras “ML” (pelas iniciais vc sabe qual é). Facilmente vc encontrará diversos modelos de MOSFET. Aconselho procurar anúncios que vendam múltiplos de 5 ou 10 unidades, pois neste caso compensará mais em termos de frete. E certamente vc encontrará lá no ML, anúncios de cidades de SC ou mesmo de Curitiba, o que implicará em custo de envio menor devido à sua proximidade geográfica.
Para o seu caso, eu recomendo usar o IRF540. Ele é muito comum e popular, e suas características elétricas atendem seu caso, pois seu “RDS ON” (“impedância ON”) é menor que 100 mili-Ohms. Com esse baixo “RDS ON”, a Potência dissipada pelo IRF540 a uma corrente de 3A, seria menor que 1W, dispensando o uso de um dissipador de calor.
Sobre o circuito, veja o exemplo mostrado na figura a seguir, que simulei no Proteus:
(clique na figura para “zoom”)
Observe as formas de onda no Osciloscópio virtual, principalmente a amplitude. Note que para o sinal que emula um PWM (na figura o sinal com nome “Pulse”), usei um gerador de pulsos, onde pode-se mudar o percentual % (portanto o duty cycle).
Veja que usei uma amplitude de 3.3V, para ficar conforme o ESP8266. Claro vc pode estar se perguntando: mas a amplitude não irá diminuir quando drenamos corrente? Sim, isso ocorre, porém no circuito mostrado o dreno de corrente da saída digital será muito baixo, e isso garante queda mínima na tensão correspondente ao Nível Lógico “1”.
Mas sobre este circuito, há outras características importantes que vc precisa estar a par. Seguem elas enumeradas:
1) veja que usei um BC337 como “driver” intermediário entre a saída digital do ESP8266 (o sinal “Pulse” no circuito), e o Gate do MOSFET. Isto é necessário para garantir sem falhas, que o MOSFET será acionado (explico logo adiante). Veja a figura a seguir onde marquei em verde claro o pior caso da tensão VGS do IRF540:
(clique na figura para “zoom”)
Veja que no pior caso, temos VGS = 4V. Isto significa que no pior caso, se a tensão de controle (o VGS) estiver acima de 4V, o MOSFET será acionado (irá conduzir). Além disso, é preciso garantir que o MOSFET conduza “bem”, ou seja, tenha um “RDS ON” realmente baixo. Com este “driver” via BC337, o “VGS ON” será de 12V, garantindo uma ótima condução do IRF540.
Esta figura foi preparada a partir do datasheet do IRF540 do fabricante Vishay. Os dados da figura estão na página 2 do datasheet, na Tabela de nome “SPECIFICATIONS”. O datasheet é este aqui: "IRF540_Vishay.pdf"
Atenção: não vá interpretar errado os valores mínimo e máximo mostrados na figura anterior para o VGS do IRF540. Eles se referem ao VGS(th) ou VGS de Threshold (ou VGS “limiar”). Quem não é especialista, vai achar que são valores limitantes para o VGS, mas esta interpretação está totalmente incorreta. Estes limites mínimo e máximo, se referem à produção (fabricação) do componente eletrônico, ou seja, se referem à estatística de fabricação. Assim, para os IRF540 produzidos e testados em fábrica, o pior caso medido para a tensão VGS(th), será 4V, o que significa que no pior caso, é preciso aplicar pelo menos 4V para o IRF540 conduzir. Obseve que no melhor caso estatístico, VGS(th) será de 2V, mas se vc considerar esse valor em um Projeto, pode dar “azar” e adquirir um componente que tem o VGS(th) mais próximo a 4V, e aí claro vai dar zica.
Sobre o valor “extremo” do VGS, vc encontra isso na primeira página do datasheet, na Tabela “ABSOLUTE MAXIMUM RATINGS”. Este valor é de 20V, e não deve ser alcançado. Aliás, se qualquer valor dessa Tabela for alcançado, o Fabricante não mais garante que o componente terá o desempenho especificado no restante do datasheet. Note que para o VDS, o valor extremo é 100V.
Pelas informações acima, vc pode concluir que se usar a saída digital do ESP8266 @3.3V diretamente no Gate do IRF540 (ou seja, sem o driver intermediário com BC337), vc não terá como sempre garantir o acionamento do MOSFET, caso o VGS(th) de algum IRF540 que vc venha a adquirir seja acima de 3.3V.
2) note que o Diodo em paralelo com o Motor (ou “anti-paralelo” como alguns preferem dizer), é um 1N4937. Este é um Diodo de comutação rápida. Não use diodos como 1N4007, ou da série 1N400x, pois estes são diodos “lentos”, que são ótimos para a rede de 60Hz, mas que são inadequados para circuitos de alta-frequência ou onde a comutação deve ser rápida. O papel desse diodo é absorver a energia eletromotriz gerada pelo Motor quando o MOSFET corta a corrente. Assim que essa corrente é interrompida, durante um curto instante de tempo, um spike de alta tensão será produzido nos terminais do Motor, e com polaridade contrária à tensão de 12V aplicada antes do corte. Como essa tensão gerada sobe muito rápido (em alguns micro-segundos ou até menos), é importante que o Diodo em paralelo, “perceba” rapidamente o surgimento dessa tensão, e absorva sua energia associada. E depois quando o MOSFET conduzir novamente, o Diodo ficará reversamente polarizado, e por ser rápido ele cortará também rapidamente, permitindo o acionamento do Motor.
Não precisa ser o 1N4937. Pode ser qualquer outro Diodo rápido que tolere altas tensões reversas (ou seja, diodos como 1N4148 não servem neste caso, embora sejam rápidos). A tensão reversa repetitiva para o 1N4937 é de 600V (lembrando que ao se colocar dois diodos em série, e com a polaridade correta, essa tensão dobrará).
3) observe que vc não deve aplicar ao Motor, um sinal PWM com qualquer frequência. A frequência que será efetiva, dependerá da Potência do Motor, ou seja, dependerá da Indutância que este Motor apresenta ao circuito. Motores mais potentes, terão maior indutância, e a frequência adequada do PWM diminui com o aumento dessa indutância. Maior indutância, menor frequência para o PWM.
Isso ocorre, porque ao usar o PWM no Motor, vc também estará chaveando uma indutância. Assim, conforme se aumenta a frequência do PWM, chegará a um ponto que o chaveamento não é mais eficiente, pois a inércia de energia do Motor girando não consegue acompanhar o liga/desliga do PWM. Assim é preciso usar uma frequência que permita aos enrolamentos do Motor “perceber” de forma clara que a corrente foi cortada, e sentir o efeito disso.
Este é um aspecto muito prático, pois além de depender da Potência do Motor, depende também da carga que está sendo acionada pelo eixo do Motor. Mas em geral, dificilmente vc precisará de mais que algumas centenas de Hz para o PWM. O ideal é começar com uma frequência intermediária, como por exemplo 500Hz, e então aumentar e diminuir a partir desse valor, observando se o controle PWM se comporta “suave”, ou se não responde mais. Claro, nesta avaliação, é preciso também variar o percentual do PWM, de 0% a 100%, para cada frequência avaliada, observando a resposta do Motor.
4) atenção: o driver com BC337, inverte o sinal PWM (vc pode conferir isso nos sinais mostrados no Osciloscópio virtual na primeira figura). Assim por exemplo para obter um PWM de 80%, vc deve programar o percentual PWM na saída digital do ESP8266, para 20% (ou seja, 100% - 80% = 20%). Para isso vc pode criar uma função muito simples que faz este cálculo e também já programa o PWM com este resultado. Se tiver alguma dificuldade com isso, avise aqui que coloco um exemplo conforme o caso ser com valores percentuais (0 a 100%) ou com valores absolutos (0 a 255 na resolução padrão do Arduino).
Caso use o Proteus e queira fazer algumas análises, segue o circuito que usei para simulação: "Motor_IRF540_Proteus.zip"
Observe no entanto, que o Motor que usei na simulação, é um dos que estavam disponíveis no Proteus. Mas vc pode ajustar os parâmetros do mesmo (como a indutância vista e a carga mecânica no eixo). Lembre-se também que a simulação “ocorre” num “tempo virtual” que sempre será mais lento que o “tempo real”.
Espero ter ajudado.
Abrçs,
Elcids…
Adicionado por Elcids Chagas ao 22:50 em 5 setembro 2020
do Hardware, certamente vc terá que usar um conversor BOOST, pois a tensão de alimentação do ESP8266 deverá ser sempre constante em 3,3V, embora a tensão nas pilhas vá diminuindo à medida que descarregam. Há excelentes conversores deste tipo no mercado, e eu já usei alguns da Texas. Por exemplo a linha TPS6101x (eu utilizei o TPS61010), que permite tirar energia da Bateria mesmo quando ela já está em apenas 0,8V. Embora o consumo do ESP8266 possa atingir picos de mais de 200mA, isto não é constante, então essa linha TPS6101x pode ser uma opção boa. Mas a família de conversores "BOOST", a TPS da Texas, é muito extensa, e há dispositivos que fornecem mais de 1A. Há inclusive o tipo "BOOST/BUCK", que trabalham com tensões de Baterias acima e abaixo da tensão regulada na saída.
Link do datasheet: TPS6101x
No entanto acho que no seu caso pode haver dificuldade para usar um TPS desses, pois eles nem sempre são disponíveis em lojas de eletrônica convencionais (talvez encontre em lojas virtuais).
Mas tenho visto à venda na Internet, diversas plaquinhas com Conversores "BOOST" prontas pra usar, e vc encontrará sem dificuldade no famoso "ML".
Atenção: os conversores do tipo "BOOST" não devem ser usados com tensões de entrada, que sejam acima da que é regulada na saída!!! do contrário, vai ter uma surpresinha desagradável.
E quanto ao Programa? quanto o seu código pode representar em termos de durabilidade da Bateria? Respondendo: uma enormidade, ou seja, mais de 80% do que se pode fazer durar uma Bateria depende do código do Programa. Em outras palavras: depende de como seu programa funciona.
E o que é preciso fazer no código? basta que só transmita e/ou receba dados, quando estritamente necessário. Exemplo: se sua janela está lá fechada e calminha recebendo a brisa do fim de tarde, e nada mais, então não há informação nenhuma para transmitir. Você não vai gastar a preciosa energia da sua Bateria numa situação dessas, não é? Então o que se faz é o seguinte: desliga-se ou coloca-se para hibernar o que gasta energia no seu Hardware, durante o tempo em que estes circuitos não são necessários.
Mas se sua janela começa a ficar nervosa com a aproximação de alguém indesejado, e é aberta, então pega o apito e sopra forte. Ou seja: você liga ou acorda os circuitos necessários para fazer a notificação do alarme, durante o tempo que achar conveniente (sem exagerar), e quando não for mais necessário, o seu código os desliga ou os coloca pra hibernar novamente.
Com esta técnica, seu Sistema só irá usar energia mais "braba" somente quando realmente necessário, e será um Sistema campeão em economia de energia.
Sobre a implementação disso tudo, não é difícil, e a lógica é tranquila. Sobre o Hardware, cuidado com detalhes, pois algumas práticas que usam por aí, costumam drenar energia de forma "invisível" (e depois o sujeito fica se perguntando como aquilo consumiu energia, se estava "desligado").
Acrescentando ao que o Kwiek disse sobre uma fonte ligada à rede elétrica: você pode usar uma fonte destas, juntamente com suas pilhas e um regulador "BOOST". Normalmente o seu Sistema seria alimentado pela energia da fonte. Se faltar energia elétrica (seja por qual motivo for), então automaticamente suas pilhas e o conversor "BOOST" entram em cena pra alimentar o seu Sistema, e sua janela não fica na mão.
Abrçs,
Elcids
…
Adicionado por Elcids Chagas ao 22:27 em 22 maio 2018
equivocadas ou criar um monte de arquivos desnecessariamente. Em todo caso, para publicar o arquivo, eu deveria ter alterado o nome.
Quanto a velocidade do esp8266, eu não imaginei que isso pudesse ser um problema, tendo em vista que utilizei diretamente com os registradores do esp32 (que acredito ser mais rápido), sem delay, e foi um sucesso. Toda via, meu conhecimento sobre os controladores é bem superficial, limitando-se apenas a funcionalidade, então pode ser que exista alguma questão no meio que eu desconheça (99% de chance disso acontecer).
Sobre o capacitor. Bem observado, não me atentei a este detalhe. Meu pensamento inicial era só para gerar um efeito de "esmaecer", isto é, ao desligar, a tela ir apagando lentamente. Nesse pensamento, eu deveria ter terceirizado o serviço, adicionando um transistor ou adicionado um resistor para limitar a corrente. Fiz o projeto baseado no ili9488 (3.5"), que possui um transistor interno para os leds.
Acreditei que todas as telas tivessem o controle do backlight, entretanto, para minha sorte (ou azar), a tela que chegou (st7735 1.8") não possui o controle do backlight, ao menos através de um pino. Em todo caso, foi um alerta muito importante. Acabei de por até o ferro de solda pra esquentar, para remover logo esse capacitor. Fiquei preocupado, achando que talvez ele estivesse contribuindo também para estes problemas.
"Para fazer uma espécie de "fader" no Backlight, há outras técnicas."
No momento, eu só consigo imaginar 2 formas, a primeira é com capacitor (595 -> diodo -> resistor -> capacitor) a segunda é com pwm (vai caindo de 100->0). Indicaria mais alguma? Apesar da placa já ta pronta, mas conhecimento é sempre bom, e evita que a gente cometa o mesmo erro novamente.
Sobre o R20
Veja a imagem a seguir (pode abrir para ficar maior)
O esp8266, suporta até 1v no analogico, mas veja na imagem, em especial no canto central da direita, é apresentado a montagem do ADC da placa de desenvolvimento do esp. Existe um resistor de pulldown de 100k e um no sinal de 220k. Isso gera um divisor de tensão possibilitando que receba sinais de até 3v3.
Como a ideia é obter sinais de até 4v2, seria necessário ainda um novo divisor de tensão. Entretanto, vendo esta montagem, adicionei + 1 resistor, no sinal, de 180k, deixando 400k no sinal + 100k de pulldown. Desta forma, poderia ser utilizado sinais próximos de 5v, gerando uma margem de segurança de 0v5~0v8.
"Se tiver algo que eu possa ajudar, não deixe de perguntar."
1- pq usar o 594 ao invés do 595?
2- Como já questionado: Quais outras técnicas podemos usar para o fade do backlight?
3- "Caso queira saber como seria esta melhoria, pergunte aqui.". Quais seriam as sugestões de melhorias?
4- Sobre os padrões. Sou iniciante na área, um curioso ou hobista, desconheço muita coisa. Vou coletando informações, testando, perguntando, liberando a fumaça mágica dos componentes (como diz RV), e colocando pra funcionar. Mas gostaria de saber: Assim que abriu o arquivo, no primeiro segundo ("Mas uma coisa que percebi, é que vc não está usando alguns padrões do mercado."), o que mais chamou a atenção para a ausência dos padrões? E onde posso conseguir informações sobre os padrões?
A única coisa que costumo colocar em excesso (não me recordo se coloquei nessa), são as larguras das trilhas de gnd. Se o projeto pede trlha de 1A, eu coloco para 3a ou mais. É excesso? Certamente. Mas como não tenho experiência, é melhor sobrar do que faltar. Ainda mais que já ouvi muitos problemas sobre as trlhas de gnd.
=== Pausa para remover o capacitor e testar o seu código ===
Já sem o capacitor, testei seu código, mas o problema persiste.
Algo curioso:
Coloquei o CI_A alternando entre 1 e 0. funcionou perfeitamente. coloquei o CI_B para ter 4 "1" e 4 "0". ficou tudo com zero.
Vou testar várias combinações para tentar trazer mais dados.…
Adicionado por tiago merces ao 12:55 em 31 agosto 2021
ital existir e funcionar.
Vamos ver por que?
Na figura a seguir, mostro a função "loop" do seu código, e vc pode ver que marquei algumas partes com cores pra ficar mais fácil me referir a estas partes:
(clique na figura para "zoom")
Rapaz, só de olhar o código na figura, já me dá um arrepio daqueles de alma-penada.
Entenda:
1) para que o OTA funcione, obrigatoriamente é preciso que o "setup_OTA()" seja executado para inicializar as funcionalidades do OTA, pois é ele (na verdade o "ArduinoOTA.begin()" ) quem "cria" aquele PORT (associado a um IP) que vc vê na IDE do Arduino, e isso deve ser feito uma única vez, já que é uma inicialização. Então o lugar adequado pra fazer isso é no "setup" do Arduino. Ok?
Mas não se iluda, pois este PORT não é um Port COM "real", ele é virtual. Ou seja, ele é na verdade a conexão a um Server criado no modo AP do ESP8266. Portanto a IDE do Arduino é um cliente desse Server.
2) mas para que o OTA funcione mesmo, também é preciso que o "loop_OTA()", seja rotineiramente executado, pois é ele (na verdade o "ArduinoOTA.handle()" ) quem verifica se em algum momento foi requisitado iniciar uma atualização OTA. Como isso ocorre? quando vc inicia uma atualização OTA na IDE do Arduino, a IDE "cliente" se conecta ao Server do AP do ESP8266, e os dois trocam "figurinhas", de forma que a IDE envie para o Server o código a ser atualizado. Por isso o "loop_OTA()" tem que ser executado rotineiramente, do contrário ele pode não detectar uma requisição para uma atualização OTA. Então, um lugar adequado pra fazer isso é no "loop" do Arduino. Ok?
3) bem, só os itens 1) e 2), já mostram a vc o que precisa ser feito pra que a coisa funcione corretamente como planejado, e quem planejou isso foram os criadores do OTA.
Mas a coisa é um pouco pior: veja o itens seguintes.
4) pra determinar quando vc quer que o OTA funcione (a seu modo), vc criou uma variável tipo "bool" de nome "OTA_ON". Por ser "bool", ela só pode assumir dois valores: ou "0" ou "1". (ou se vc preferir: ou "false" ou "true"). Não há como sua variável "OTA_ON" assumir outro valor que não seja um dos dois listados. Então para testar o "OTA_ON", basta que vc teste verificando um dos dois valores ("0" ou "1"), pois se não for o que vc está verificando, só poderá ser o outro. Não há como existir um terceiro valor possível e uma terceira possibilidade de teste.
Mas no seu código, há três possibilidades, pois há um "if" que testa se "OTA_ON" é igual a "0", onde marquei em roxo na figura anterior (note que a parte do "millis" não muda as coisas, pois no final das contas o resultado será "0" ou "1" de qualquer forma). E se não for "0", então "OTA_ON" só pode ser "1", mas no seu teste vc está verificando isso de forma desnecessária marcado na cor laranja). Mas como se não bastasse essa doidera, vc ainda tem o "else", que seria executado caso "OTA_ON" não fosse nem "0" nem "1". Mas como assim?????? Percebeu porque o George Boole certamente está revirando no túmulo?
Então veja que o que está na parte marcada em amarelo, jamais será executado, pois como "OTA_ON" é tipo "bool", ou será executado a parte na cor verde, ou será executada a parte na cor azul. A parte na cor amarela, sem chance.
5) mas a coisa piora um pouco mais. Como eu disse, para que o OTA funcione, é preciso que o "setup_OTA()" tenha sido executado antes e uma única vez. E depois disso, o "loop_OTA()" deve ser executado rotineiramente. Mas na lógica mostrada na figura anterior, ou será executado a parte verde, ou será executada a parte azul. Jamais as duas partes serão ambas executadas. Então já viu, né? Não tem como o OTA funcionar naquela lógica.
Tá bem doido isso, né?
Nota: sua justificativa pra não deixar o OTA sempre "ativo e consumindo energia", não tem sentido, pois a execução rotineira do OTA é otimizada de forma a não ficar perdendo tempo caso nenhuma atualização seja requisitada (justamente pra ter o menor impacto possível no restante do código, e esse objetivo é alcançado, pois o ESP8266 é um Processador bem rápido).
Que tal vc analisar isso melhor, e talvez decidir fazer as coisas como elas foram planejadas para serem feitas ?
(se vc quiser navegar no mar com a fuselagem de um avião, pode tentar, mas o avião não foi exatamente planejado pra isso, logo algum problema vc vai ter)
Obs.: não fique bravo comigo. O objetivo não é ser duro com vc. Mas que eu imagino o George Boole revirando no túmulo, eu imagino.
Abrçs,
Elcids…
Adicionado por Elcids Chagas ao 5:59 em 4 fevereiro 2022
ansmitter )
RXD0 ( GPIO_3 / pino 25 do chip) : Esse é pino de recepção da interface serial 0
TXD0 (GPIO_1 / pino 26 do chip) : esse é pino de transmissão da interface serial 0
IO_2 ( GPIO_2 / Pino 14 do Chip):Obdecendo configuração do firmware, para boot da memória Flash durante o reset, esse pino deverá ter o nível alto - conecte um resistor de 10K ohms ao +3,3V. Para o modo de download através da interface serial UART, esse pino também deverá estar no nível alto (3,3V).
IO_0 ( GPIO_0 / Pino 15 do Chip): Atenção !Obdecendo configuração do firmware, para boot da memória Flash durante o reset, esse pino deverá ter o nível alto - conecte um resistor de 10K ohms ao +3,3V. Mas para gravar a memória Flash usando o modo de download através da interface serial UART, esse pino deverá estar no nível nível baixo (zero Volts - conectado ao terra).
RST (EXT_RSTB / Pino 32 do Chip) :
Esse é o pino de Reset do Chip ESP8266EX. Esse pino já tem um resistor interno de pull-up, por isso, não é necessário conectar algum resistor. Para resetar o chip (reboot) , use um nivel baixo - conecte o pino ao terra (um pulso apenas).
CHIP_EN (CH_PD / Pino 7 do Chip):
Como o nome já diz, Chip enable, isto é ativação do Chip. Para o funcionamento normal do módulo, esse pino deverá ter um nível alto (3,3V). Como esse pino já tem um resistor interno de pull-up, não há necessdade de conectar algum resistor. Para desligar o chip (power down), conecte esse pino ao terra.
Apesar do Datasheet informar que o pino tem um resistor de pull-up, ao testar o meu módulo ESP-201, constatei que o pino CHP_EN estava sempre com zero Volts. Por isso, para ativar o módulo, precisei conectar um resistor de 10K ohms ao +3,3V.
Para gravar na memória Flash, o pino GPIO 0 deverá estar no nível baixo (zero Volts) somente durante o power on (energizando o módulo), Assim que o Chip entrar no modo de download do FW, pode liberar o pino.
Se estiver usando um botão, poderá deixar de pressionar o botão.
IO_0 ( GPIO_0 / Pino 15 do Chip): Atenção !Obedecendo configuração do firmware, para boot da memória Flash durante o reset, esse pino deverá ter o nível alto - conecte um resistor de 10K ohms ao +3,3V. Mas para gravar a memória Flash usando o modo de download através da interface serial UART, esse pino deverá estar no nível nível baixo (zero Volts - conectado ao terra).
…
nte.
Algumas placas, durante a fase de projeto, coloquei na protobard para testar cada detalhe e verificar todos os possíveis problemas, entretanto, existiram algumas que não foram testadas, tornando-se produções 100% teóricas.
Dentre elas, desenvolvi uma plaquinha para me ajudar com dados sobre baterias de li-ion. Então vamos lá.
Objetivo:
1- Carregar até 3 baterias individualmente
2- Obter informação de carga
3- Obter informação de temperatura
Métodos:
- p/ objetivo 1: através de módulos com o tp4056.
- p/ objetivo 2: através da descarga da bateria, utilizando um resistor de 5r e 10w.
- p/ objetivo 3: sensor de temperatura ds18b20
Visualização das informações:
- Tela TFT LCD 1.8"
- 3 Leds RGB
Lista dos materiais utilizados e seu objetivo:
A) 3x 74hc595: Acionar leds, mosfets e alternar o controle do cd4051.
B) 1x 74hc165: Teclado de 6 botões apenas.
C) 1x CD4051: "expandir" portas de entrada analógica (multiplexando)
D) 1x Esp8266 (módulo): controle geral e cálculos
E) 3x Resistor 5r 10W: Dreno das baterias
F) 6x IRF540n: chave para acionar "dreno" ou "recarga"
*Para dreno, o mosfet se ligará com o resistor
* Para recarga, o mosfet ligará a alimentação do tp4056
G) um monte de resistores
H) 1x cap. 470uf eletrolítico: Produzir um efeito de esmaecer ao desligar o brilho da tela.
I) 1x cap. 1000uf eletrolítico: Força do hábito (está ligado ao +5v, que alimenta a placa)
Segue imagem em 3D da placa:
Imagem do circuito no proteus:
Imagem do esquema.
obs- a imagem está com uma resolução muito grande, recomendo fortemente a abrir em uma nova janela.
obs- Em anexo está o arquivo do proteus e o gerber, caso seja necessário.
//////////////////////////////////////////////////////////////////////////////////////////////////
Placa chegou, soldas prontas, conectores no lugar, então inicia o teste por etapas.
---Status---
1) Tela de LCD. Funcionando perfeitamente
2) 74hc595: Não funcionou
3) devido ao 74hc595 não funcionar, o 4051 não pode ser testado.
4) devido ao 74hc595 não funcionar, os irf540n não pode ser testado adequadamente.
5) devido ao 74hc595 não funcionar, o tp4056 não pode ser testado com a placa.
6) 74hc165. Funcionando perfeitamente.
Vale lembrar que, devido a um planejamento equivocado, só posso upar o código se o controlador ou o 74hc165 estiver fora da placa, pois o pino "data" do 165, está conectado ao RX, impossibilitando a boa comunicação do a serial.
Quanto ao código, também em anexo, existem 3 pontos que estou utilizando para definir os ci's, por completo, como alto ou baixo (linha 13, 17 e 22), meus resultados estão sendo o seguinte:
74hc595 C = 0 // Off
74hc595 B = 0 // off
74hc595 A = 1 // ON
Resultado: Apenas "A" ativo.
74hc595 C = 0 // OFF
74hc595 B = 1 // on
74hc595 A = 1 // on
Resultado: A, B e C ativos (deveria ser apenas A e B)
74hc595 C = 0 // OFF
74hc595 B = 1 // on
74hc595 A = 0 // on
Resultado: B e C ativos (deveria ser apenas B)
74hc595 C = 0 // OFF
74hc595 B = 1 // on
74hc595 A = 0 // on
Resultado: NENHUM ativo (Deveria ser apenas C)
obs- na postagem seguinte, irei fazer a lista completa.
Bibliotecas utilizadas:
TFT eSpi: https://github.com/Bodmer/TFT_eSPI
Problemas já encontrados e "resolvido":
Acionamento dos leds.
Existiu uma falha no projeto, onde realizei os links de forma errada. O link deve ser feito através de 1 "apelido" em 2 ou mais terminais distintos. Entretanto, errei o apelido, isto é:
LedR1 (em um terminal) e Led_R1 (em outro terminal), desta forma, os leds ficaram conectados ao resistor, mas os resistores não possuem qualquer conexão no segundo terminal.
Solução: Puxa um fio e solda, por baixo da placa. Fim.
Problemas pendentes
-74hc595 que não funciona como deveria.
…
Adicionado por tiago merces ao 0:45 em 31 agosto 2021