Confiabilidade no pic

[lucasromeiro]

Boa noite galera!!
Eu já programo tem alguns anos.
Porém, observei que acontecem bugs inesperados.
Difícil acontecer, mas acontece.
Então minha GRANDE dúvida é:
Como proceder para dar a maior confiabilidade possível para o bom funcionamento do PIC?
Estou fazendo uma aplicação muito importante e não pode falhar em hipótese alguma.
Penso em por um wdt externo para monitorar o bom funcionamento.
Mas acredito que não seja suficiente.
Então existe alguma ou algumas práticas para assegurar que o programa está rodando bem?

[EDSONCAN]

Crie redundâncias de preferencia do sistema todo, mas lembre-se que o Ônibus espacial tinha 5 computadores IBM e os cálculos mais críticos eram feitos pelos astronautas usando uma HP41C, ou seja, todo sistema tem falhas --- até explodiu um deles---- interessante que eram bem ultrapassados para a época, mas o processo de homologação desses computadores levavam anos e não havia como usar tecnologia de ponta.

[andre_luis]

Ao menos para alguns desses bugs há soluções de contorno conhecidas.
De que exatamente voce tá falando ?

[lucasromeiro]

Crie redundâncias de preferencia do sistema todo, mas lembre-se que o Ônibus espacial tinha 5 computadores IBM e os cálculos mais críticos eram feitos pelos astronautas usando uma HP41C, ou seja, todo sistema tem falhas --- até explodiu um deles---- interessante que eram bem ultrapassados para a época, mas o processo de homologação desses computadores levavam anos e não havia como usar tecnologia de ponta.

Obrigado Amigo.
Mas efetuar redundancias de hardware tornaria o hardware maior e mais caro, portanto incompatível....

[lucasromeiro]

Ao menos para alguns desses bugs há soluções de contorno conhecidas.
De que exatamente voce tá falando ?

Olá amigo,
Poderia me falar estas soluções?
Na verdade não ha como eu dizer o que acontece, porque o pic simplesmente trava ou executa funções de forma errada.

imagine um loop infinito sem nada dentro...
Teoricamente nao ha codigo para dar algum erro.
Inesperadamente o pic para.

Não é isso que ocorre, pois eu tenho código funcionando.
Mas o principio é o mesmo!!
Pois tenho um projeto que funciona ha meses.
Mas outra placa com o mesmo código, travou inesperadamente.
Foi somente uma vez! A placa simplesmente enviou dados inconsistentes que não tinham nada haver com o que ocorria no momento e depois travou de vez...

Apesar de ter sido somente uma vez, não posso ter risco de isso ocorrer.

Para evitar tratamentos eu botei um WDT externo!

Mas ele nao detecta o mal funcionamento do pic caso esteja interpretando de forma errada o código ou algo interno..

Não sei o que acontece, mas ja vi vários projetos travarem inesperadamente...
Não sei se tem alguma técnica que ajuda nesta questão.
Qualquer coisa que puder me passar que ajude a manter funcionando bem o pic eu agradeço.

Preciso evitar AO MAXIMO qualquer travamento.

[Silvio51]

Lucas...eu não costumo acreditar em "coisas do além"...e partindo deste princípio, acredito que exista alguma razão para algumas coisas acontecerem.

Tenho enfrentado alguns problemas com microcontroladores e tenho conseguido sanar bem estes problemas, se não resolvendo por definitivo, mas também muitas vezes "work around".

Em vez de já "determinar" que o problema é no microcontrolador (esse que você chama de PIC), será que já se esgotaram as chances de ser o seu hardware ? Ou talvez o seu software ? Ou o compilador ? Ou seu firmware foi gerado corretamente ?...problemas de Interferência eletromagnética (EMI), ruído vindo da fonte ? Observou com Osciloscópio? Têm harmônicas nesta rede ? Como está o desacoplamento das trilhas de potência ?

Sei que são muitas perguntas e que você já deve ter verificado a grande maioria mas acredito que a "materialização" em algum caso concreto pode ajudar mais para entedermos o problema.

Tive até ontem, um problema com um DSPIC da família 30F...nunca tinha tido problema semelhante...apesar de não ter encontrado a "causa raiz" do problema (suponho que seja minha "fonte pobre" gerando ruído demasiadamente) consegui eliminar o incoveniente ativando recursos do micro (PBOR, Brown Out e Power On Reset)...neste caso específico, o meu micro pode estar "reiniciando" algumas vezes durante o Power On (em algumas frações de micro segundos) o que não me gera nenhum problema...

[msamsoniuk]

eu diria que existem duas formas bem populares: redundancia com dois processadores ou redundancia com tres processadores:



com dois processadores vc tem um processador master e um slave. como no desenho acima, o slave verifica se o master esta consistente. se houver divergencia, o slave gera um indicativo de erro, que obriga o master a tomar uma atitude para corrigir o problema (pode reiniciar, recalcular ou tratar uma interrupcao para corrigir o erro). o outro esquema utiliza tres processadores e um esquema de votacao: se houver divergencia, a maioria vence. no primeiro esquema, o erro sera detectado e corrigido. no segundo o esquema, o erro sera ignorado e a maioria vence.

um exemplo pratico de redundancia tripla:



este esquema eh usado em circuitos integrados que precisam sobreviver em ambiente de alta radiacao. por exemplo, as entradas podem vir de tres flip-flops ativados simultaneamente. se um flip-flop falhar, a maioria simples vence, mas nao existe verificacao se houve falha ou nao.

neste caso, talvez a combinacao das duas tecnicas seja o apice da redundancia maxima: um par de sistemas, cada um com tres processadores e sistema de votacao. um sistema operando como master e outro como slave, verificando. neste caso, uma falha simples de um processador em cada sistema vai ser corrigida em tempo real pelo sistema de votacao. a falha de dois processadores, no entanto, vai causar divergencia no sistema master/slave e a falha sera detectada e corrigida.

[Red Neck Guy]

Vou dizer que é legal essa teoria de redundância, porém, acho que não seja o caso do autor deste tópico.
As vezes, pode ser algo não inicializado, algo não esperado no programa para uma determinada inicialização, coisas do tipo.
Sei que as vezes tu olha pro código e não vê nada, mas pode acreditar o bug está lá.
Tenho projetos com PIC que rodam 24h por dia 7 dias por semana, e nunca travam. (Tá bom, as vezes algum dá pau na fonte, mas não entra pra nossa estatistica de problemas)

[xultz]

Vou contar um causo bizarro. Fui incumbido pela empresa para auxiliar na instalação de um conjunto de equipamentos que a empresa produz do outro lado do país. Este equipado é produzido há alguns anos e tem muitas instalações que estão rodando bem até hoje.
Foi feita a instalação, e neste conjunto tem uma série de equipamentos que os usuários utilizam, tem um botão nele, e eles se comunicam por RS485, e usa uma caixa de plástico injetado. O equipamento é tocado por um PIC16. Tudo simples, tudo pé de boi. No local foram instalados em três salas diferentes. A primeira estava com um comportamento estranho, quando eu apertava o botão de alguns aparelhos, eles se comportavam com tivessem ressetado. Mexe daqui, fuça dali, troquei a tomada que alimentava o conjunto inteiro para outra na mesma parede e o problema parou. Na segunda sala, nenhum problema.
Na terceira sala, onde tinha quase 5 vezes o número de dispositivos, deu o mesmo problema. Quando eu trocava aparelhos de posição, o problema persistia, mas na posição, não no aparelho. O treco era tão bizarro que se eu colocasse um livro embaixo do aparelho, o problema parava. Eram 7 da noite, minha passagem era prás 11 da noite e comecei a tentar todo tipo de soluções aleatórias, lá pelas 9 o problema tinha parado, testei por uma meia hora, chamei o cliente, ele aceitou a instalação e eu vim embora.
Obviamente, na semana seguinte o problema apareceu de novo. Ficamos uma semana tentando repetir o problema na empresa, mas não acontecia nada nem parecido. Nem nenhum cliente já tinha reclamado alguma vez de algo semelhante. Voltei pro cliente, munido de osciloscópio, ferro de solda, esquemáticos, tudo que tinha direito. Fui no local que o problema era mais evidente, e comecei a ver os sinais. Medindo o reset do PIC, quando chegava com o dedo a uns 5 mm de distância, começavam a aparecer pulsos, bem evidentes. O PIC tinham algumas GPIO sem uso, e o sinal aparecia forte ali. Depois de tentar algumas coisas, liguei estes pinos todos com fio direto no pino de GND do PIC, e o problema sumiu totalmente. Repeti o processo em todos os dispositivos que foram instalados, e eles não mostraram mais nenhuma zica. Isso já faz mais de um ano, e continuam firmes e fortes, sem dar nenhum problema. O interessante é que todas estas GPIOs estavam configuradas como saída em nível baixo.

Por que raios isso só aconteceu ali, nunca aconteceu antes? Por que somente em alguns pontos da sala? Que indução eletromagnética do capeta tinha naquele local? Eu até hoje não sei responder, mas que eu vi acontecer, isso eu vi.

[vtrx]

Programe rotinas críticas em linguagem de máquina,se possível...

[B-EAGLE]

O interessante é que todas estas GPIOs estavam configuradas como saída em nível baixo.

é, isso torna a parada bem bizarra mesmo, se as linhas de alimentação estivessem tudo ok...

[B-EAGLE]

mas pela minha experiência, 99% das vezes esses problemas 'inexplicáveis' eram firmware.

variável sendo usada em mais de um lugar sem usar 'volatile' na delaração...
no caso dos PIC, quase fiquei doido uma vez por setar uns pinos dando SET no PORTx, e não no LATx...

e por aí vai.... o melhor mesmo é começar olhando o código bem calmamente

[MOR_AL]

Todo grande problema pode ser resolvido, caso exista uma solução.
Procure separar o procedimento de identificação do problema em etapas.
Por exclusão, siga o que o Silvio51 apresentou em postagem anterior, que você encontrará a fonte do problema.
MOR_AL

[andre_luis]

Todo grande problema pode ser resolvido, caso exista uma solução

Como diz o provérbio chines...."todo problema de hardware pode ser contornado por software"

Mas numa certa ocasião usei um PIC16C84 num projeto que tinha uma chave com um resistor Pull-up de 10K no pino RA4 configurado como INPUT ( o tal pino que quando configurado como OUT, é open-collector ), e o uC travava quase todas as vezes que a chave era pressionada. Após colocar um resistor de 100R em serie do PIC para a junção chave+pullup, não deu mais problemas. Não sei se corrigiram isso de 15 anos pra cá, mas fica a dica.

[longo.251272]

Bom dia pessoal.

A alguns anos atrás eu usava um pic de pinos para acionar um motor de passo pequeno de 12 V que funcionou por 3 anos sem problemas, porem num lote de pic's que veio pra mim começou a ocorrer o travamento ou o reset dele inesperadamente.
Pesquisando achei uma possível relação, a Microchip tinha reduzido o tamanho do núcleo dele utilizando uma tecnologia mais moderna.

Na mesma época estava fazendo um projeto novo com a família Attiny da Atmel e resolvi usar um de 8 pinos para colocar no lugar do PIC, nunca mais tive problemas.

Sei que o projeto não estava bem projetado em relação a ruídos, só to colocando o ocorrido.