Conflito entre DISPLAY LDC com I2C,TIMER1, RT1307, DS18B20 ,ARDUINO UNO

Busco  respostas para corrigir um erro de programação 

Quando utilizo a biblioteca simples de LiquidCrystal  com o TIMER1 , RT1307, DS18B20  funciona normalmente.

Mas quando utilizo a biblioteca LiquidCrystal-I2C   com o TIMER1 , RT1307, o display inicia normalmente e após a varredura inicial para de funcionar .

Estou utilizando o TIMER1 devido  a necessidade de interromper o ciclo  para atualizar a tela do display  de  indicação das horas , temperatura, que ocorre  de 1 em 1 segundos para o ciclo de funcionamento de indicação no display .

Em anexo coloco a disposição de todos que puderem me auxiliara a encontrar  uma maneira mais simples de solucionar este problema.

Obrigado por poder compartilhar  minhas dificuldades  com vocês.

Meu conhecimento é na área de automação industrial , mas sinto necessidade de entender o que se passa de errado no programa . 

Alguns trechos foram retirados de sketch já produzidas .

Teimosia minha,  mas pretendo  se possível com auxilio de vocês solucionar o que se passa nesta sketch

Obrigado. 

JÁ EH !!!!

Exibições: 683

Anexos

Responder esta

Respostas a este tópico

Bom dia Sr. E ,   (se não gosta que te chame pelas iniciais, avise),

em conversa com o MCS, entendi que a necessidade de é um processamento paralelo.

Como isto não é viável( eu diria até impossível)  na plataforma do Arduíno, eu sugeri que ele

estudasse e aplicasse no projeto dele o conceito de threads.

Ele ficou de estudar e nos retornar para ajudarmos nas dificuldade com esta novo " approach".

RV

olá RV.

      Na verdade é possível sim.  O conceito de "Threads" é genérico, e não abrange uma forma específica e única de implementar isso.

      Analisei o código do Marlen com bastante cuidado.  E o "Processamento Paralelo" que ele deseja, nada mais é do que uma exibição no Display (e na Serial do Arduino), dos dados atuais de controle, enquanto o próprio controle se desenrola.  E isto é perfeitamente possível, e irei demonstrar isso neste post.

      O grande problema por enquanto,  é que o código original,  tem alguns pontos duvidosos. Alguns destes pontos são muito evidentes, mas há alguns bem mais sutis.  Levantei todos eles, e se o Marlen deixar claro como deve ser, então bastará fazer a implementação.

      Irei também postar uma simulação deste Sistema, para facilitar os testes, e para aqueles que querem "treinar" o processo de implementação.

      Mas se o Marlen desistir e seguir para um "approach" diferente, tudo bem.  Poderei publicar um entendimento do funcionamento, e aí a coisa segue da forma espontânea.

      Aproveito RV,  para dizer,  que não esqueci da proposta que fiz sobre o tópico de implementação das MV's, na qual considero sua ajuda essencial, uma vez que sua imensa experiência aqui no LDG é inigualável.  Sobre o "script" que prometi, irei te enviar em breve,  e se for do interesse, discutirmos a respeito.

      Abrçs,

      Elcids

Boa tarde Rui, 

Se ele for usar um dispositivo de cada vez, não há necessidade de processamento paralelo. 

Coloque o TIMER1 como prioridade na execução do programa. 

Threads deve mesmo resolver o problema dele. 

olá Murta.

      Na implementação que o Marlen está tentando, nem é necessário usar o TIMER1,  e este recurso pode ser poupado.

      Ocorre que em algum lugar e em algum momento, o Marlen "pegou" esse uso do TIMER1 como meio de implementar o Sistema, a e partir daí passou a achar que era esse o caminho.  Mas isso não é necessário, mesmo sendo o Sistema dele do tipo "real",  uma vez que todos os elementos neste Sistema são "lentos" em termos de processamento e com interface humana também "lenta".

      Abrçs,

      Elcids

Bom dia  Elcids!

Todas desligadas!

Ok Marlen, vamos em frente então.

      Uma vez que vc disse que na linha 739todas as saídas digitais devem começar desligadas, há pelo menos dois pontos conflitantes com isso.  Um deles é bem evidente, e irei questionar esse primeiro logo adiante. O segundo é mais sutil e por isso irei questionar o mesmo depois.

      Para vc entender o primeiro ponto contraditório, veja a figura a seguir, onde mostro o trecho final da função "setup":

(clique na figura para "zoom")

      Observe a região onde marquei na cor amarela, entre a linha 721 e a 724.

      Nestas quatro linhas,  todas as saídas digitais  são ligadas.  Após isso,  a função "setup"  termina sua execução.  E logo em seguida disso,  é iniciada a execução da função "loop".

      Então Marlem,  como vc explica isto,  uma vez que ao iniciar na linha 738 da função "loop"  vc disse que todas as saídas deveriam estar desligadas ?   Mas como vc vê, assim que o Sistema executa pela primeira vez, isso não ocorre, porque ao deixar a função "setup",  todas as saídas estão ligadas.

      Por favor, deixe claro.

      Assim que tiver sua resposta,  então irei colocar a próxima questão, que é um pouco mais sutil sobre o funcionamento.

      Elcids

Boa tarde!

A lógica estaria toda inversa !  

Na minha lógica seria para iniciar tudo desligado mesmo . 

Porque quando vc envia o código para o arduino e após carregado não acontecer de dar um pulso nas saídas e retornando desligado ( apesar de ser muito rápido).

E a outra questão que na linha 827 termina tudo para poder iniciar novamente .

Caso ocorra de terminar na 827 e se  algumas das entradas abaixo estiverem 

pHabTransp,  desligada  ou
pEmerg,         ligada ou
pSiloCheio      ligado 

não libera a linha 740 adiante até que todas acima estejam em condições opostas

pHabTransp,   ligada 
pEmerg,         desligada 
pSiloCheio     desligado 

Grato 

Marlén

Marlen,  por favor:  não responda com informações adicionais (não dá pra mim ficar te pedindo isso a todo instante). Estas informações adicionais, ficam fora do contexto da pergunta e bagunçam o entendimento da lógica. Isto não é uma frescura da minha parte. É a forma como se implementa um Sistema. Espero que entenda isso.

      Como vc não escreveu claramente como deve ser,  então vou assumir que ao iniciar o Sistema (quando o "setup" inicia)  e ao sair do "setup", todas  as saídas devem estar desligadas.

      Também vou assumir que ao iniciar na linha 738 (no início do "loop") as saídas devem estar todas desligadas.

----------------------------------------------------------------------------------------------------------------------------

      Agora vou à próxima questão, que como eu disse, é um pouco mais sutil. Esta questão, se refere também à uma contradição. Porém neste caso, vc provavelmente terá que pensar um pouquinho mais pra analisar e responder.

      Veja:  na linha 831  termina a execução da função "loop".  Porém antes,  poderá ter ocorrido de ter sido acionado o "alarme",  isto nas linhas 777 e 781.  Neste caso,  após passar pela linha 799,  e não entrar  na linha 806,  o Sistema segue para a linha 824.  Então após isso, termina o ciclo na linha 829, e termina a execução do "loop".  E após isso,  o "loop" é iniciado novamente, lá na linha 736.

      Veja Marlen, que ao final da sequência descrita acima, a saída digital  "pAvisoFalhacomeça ligada  no início do "loop".  Então como deve ser afinal?  O que deve ser feito?  Quando de fato a saída "pAvisoFalha"  será desligada?

      Analise com cuidado, para poder fornecer uma resposta que tenha sentido no funcionamento do Sistema.

      Elcids

Boa tarde MCS,

abaixo segue seu sketch modificado pra rodar usando threads.

Retirei os vários "Serial e LCD begin"  que estavam travando o sketch.

Minha sugestão é que  você comente todas linhas do sketch e que o organize melhor.

Testei aqui e funcionou como acho que deveria funcionar, mas só você que sabe como deve funcionar.

RV

Threads_Areia.ino

Boa tarde MCS.

E  aí, funcionou?

RV

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço