arduino, eletrônica, robotica...
RESET usando o pino "reset"
Bom Dia Srs;
estou com um problema de travamento que não consigo solucionar de jeito nenhum...
a medida "paleativa" que achei foi resetar o arduino de tempos em tempos... tentei utilizando ASM VOLATIME, e WATCHDOG. os dois deram uma sobrevida ao sistema, mas não resolveram, pois o travamento bloqueava a rotina, e assim eu não conseguia acionar a rotina.
em muitos sites vi que o RESET usando o pino (ao lado do 3.3v) era altmente desaconselhável, ("... reset físico com transistor: um engenheiro da Atmel morre de infarte cada vez que alguém faz isso...." achei muito boa essa citação)
mas enfim pesquisando vi que o problema do reset fisico é o tempo em que o pino permanece em LOW, senso assim fiz um esquema com e n555 mais um capacitor e uma porrada de transistor, resistor, diodo...
basicamente o primeiro n555 recebe um pulso do proprio arduino no inicio de cada loop, este alimenta um capacitor que por sua vez dispara o segundo n555, que aciona o reset.
com esta configuração consegui que caso o 1º n555 fique mais de 3,7s sem receber o pulso GND, ele dispara o 2º n555 que mantem o reset em LOW por 1s (1097ms precisamente)
minhas dúvidas são:
1) existe alguma outra contra indicação?
2) este tempo de 1s seria suficiente para "zerar" toda a memoria, e fazer um reset correto? qual seria o valor minimo? (acredito que quando pressionamos o botão ele não fica em contato por 1s)
3) porque a arduino já não coloca esse timer embutido na placa, assim um simples pulso resolveria!!!!!!
Respostas a este tópico
-
Permalink Responder até Marcelo Mosczynski em
-
Vc está verificando que precisa do reset porque a comunicação cessa, ou você tem algum tipo "ação" que deixa de ser executada?
-
Permalink Responder até Millencolinhc em
-
a rotina toda trava, ele não responde nenhum comando e tb o serial monitor para...
um dos pontos que estava com problema era o uso do SD com o Ethernet... mas fazendo as ativações e desativações dos pinos 4 e 10 melhorou 50%...
agora acho que tem mais a ver com os multiplexadores i2c, que estão a uns 10m do arduino... já vi que isso dá problema... tem a ver com impedância, mas não manjo muito isso...
achei mais facil fazer o reset... está funcionando 100%
(creio que não seja a saida mais elegante... mas por enquanto é o que to podendo fazer!!!!!)
-
Permalink Responder até Jonatas Freitas em
-
Um reset físico na placa standart acho que iria causar um bucado de projeto em loop infinito, uma vez que a própria necessidade do reset (cá pra nós, uma gambiarra) é indicativo de que algo não vai bem.
Quanto ao I²C... 10 Metros?!! Agora quem infartou foi um engenheiro da Philips.
*o que você tem contra engenheiros? =D
I²C foi criado para interligar dispositivos em uma mesma placa, no máximo em placas adjacentes (conectados por conectores ou cabo flat).
Exigir 10m do I²C é como exigir 10Km de um Ethernet por par trançado.
Recomendo a você fazer um tunelamento utilizando um outro protocolo de hardware, mais adequado a esta distância.
-
-
Agora que você colocou isso, que lembrei, o problema não é os 10 metros, a biblioteca padrão que vem para controlar I2C no arduino tem um bug, que "congela" o programa se há um problema na comunicação dos devices.
Eu fiz testes com cabos de 6 metros conectando 2 atmega com I2C e as vezes ocorria esses congelamentos, principalmente no master, que não recebe o "ok" do slave.
Não fui mais a fundo em como resolver porque mudei para RF433, mas há um patch para esse problema, tem apenas que procurar.
-
-
Tem solução para as perdas causadas pela atenuação?! Tem! Até cabo Ethernet o pessoal consegue passar dos 100m. Uma extensão USB (padrão do protocolo é 1.8m) também funciona a taxas mais baixas.
Mas é tudo gambiarra. Aí tem que correr o risco.
Caso realmente queira ficar no I²C, é possível utilizar um CI extensor de I²C. Um exemplo é o 82b715:
Aí pega teóricos 100khz a 30metros (só testei a 5m, com uma leve perda de velocidade).
-
-
Bem interessante, estava dando uma olhada no que consigo entender no datasheet!!! e nas recomendações da philips sobre o I²C, nem cogitei isso quando estava bolando o circuitinho hahah, a idéia foi exatamente sair com menos fios da caixa onde fica o arduino...
e é justamente o que não é recomendado para o I²C!!! mas enfim está funcionando por enquanto não vou mexer nas plaquinhas, por motivo de R$ mesmo... mas para uma próxima atualização com certeza vou considerar umas alterações hehehe
até o momento não me faz muita diferença perder alguns segundos caso ele perca a comunicação (considerando que esse travamento ocorria a cada 2 dias) e da forma que está não perco nenhuma informação.
Aproveitando o ensejo, alguém tem uma outra saída para criar módulos remotos de distribuição de sinal para controlar reles, que fique barato como com o 8574??
-
-
complementando estava pensando aqui e poderia criar um tipo de adaptador com este esquema e coloca-lo no plug da placa que ja tenho, será que funciona, assim não preciso refazer a placa de distribuição
-
-
É uma alternativa.
Vai diminuir essa atenuação que tens hoje.
-
-
vou fazer o teste, mas to considerando fortemente outras alternativas só achei o chip em 1 lugar pela net e custando 12 pilas!
-
-
Se eliminar toda essa gambiarra com um par de 555 "mais um capacitor e uma porrada de transistor, resistor, diodo", tá valendo o custo, não?!
-
-
é bem possível heheheheh
mas no final acho que não, pois pela recomendação do datasheet preciso de 1 par de 82b715 para cada dispositivo.
ou seja se tiver mais de 16 lampadas ja são R$96,00.
na melhor das hipóteses 1 prox ao arduino e 1 em cada ponto = R$48,00 + placas, conectores, caixa... ( e subindo!)
acho que a solução correta é pular fora do I²C PCF8574!
considerando ainda que eu sou pato nessa brincadeira, acho que não teria confiança suficiente no meu projetinho para retirar esse "sistema de emergência" (dei um nome bonito pra GAMBIARRA, assim me sinto menos apelão!!!)
e tb o "sistema de emergência" !!! eu coloco na placa principal que estou montando, tenho o custo só dos componentes que deve ser de uns 8 mango no máximo.
mas independente de qualquer coisa vou pegar um chip desses nem que seja só pra ver como funciona (é sempre bom aprender!)
-
-
kra procurando na net, achei uma atualização da wire.h que diz resolver o problema do congelamento, tem a ver com um "erro 5" que não existe... (não entendi muito bem) mas parece que o kra alterou para "erro 6" não tenho ideia do que significa... mas ta valendo!
acabei de baixar aqui e funcionou, só tive que alterar o resistor, pois se entendi direito nesta atualização foi desativado o ¿pull-UP interno?, sendo necessário um pull-up externo,
ta rodando... vou deixar sem a gambiarra do reset para ver se para o travamento.
Bem-vindo a
Laboratorio de Garagem (arduino, eletrônica, robotica, hacking)
© 2024 Criado por Marcelo Rodrigues.
Ativado por
