fiabilidade codigo.

[dio123]

Desenvolver um projecto para nosso lado pessoal,  no qual o seu funcionamento vai estar 24h/7dias temos de garantir e tentar prevenir as 1001 coisas que possa acontecer. Tanto hardware com software.

Já li a uns tempos mas nao me lembro muito bem do contexto em que users tinham problemas com o codigo em que funcionava muito bem durante +/- 2 dias e depois atmega bloqueava.  E num dos casos  problema era _delay_ms();

A minha pergunta é como posso testar  e garantir a mim mesmo que o meu codigo  ou mesmo simples código led blink num atmega o codigo deixe de funcionar daqui a 1 semana?

Assim como o meu vizinho tem o Portão automático com attiny2323 que a +2anos e que nunca falhou.                                       

[jm_araujo]

Tudo depende de até onde queres ir.
O básico e se a função o permitir seria meter um watchdog (sw ou hw): quando falhar/bloquear faz reset e "limpa" o problema. Porque mesmo o sw "perfeito" não te evita que o micro não bloqueie por causa de radiação, um fenómeno eletromagnético ou outro imprevisto qq.

Nível seguinte é limitar ao mínimo a utilização de funções arduino, não usar bibliotecas de 3ºs , e as essenciais usadas dar umas vistas de olhos à sua implementação e dependências em timers e afins para evitar surpresas.

Nivel "extremo" seria mandar o código arduino com as couves. As bibliotecas do arduino são um poço sem fundo de possíveis problemas, se queres sw estável tens de controlar todo o teu código.

Assim de repente seriam os principais vetores de ataque a esse problema, tendo em atenção que não mutuamente exclusivos.

[Sérgio_Sena]

A melhor solucao eh bootstraping.
Aprende a programar um micro de forma convencional, i.e. sem ambiente arduinos, e podes controlar o teu codigo por completo.

Como o @jm_araujo ja disse, o Watchdog eh dos perifericos mais importantes p manter uma "certa" fiabilidade no produto. No entanto, mesmo q o codigo esteja "perfeito", ha sempre gremlins.

Os AVR sao excelentes micros, com uma excelente fiabilidade. Descarrega o IDE q a Atmel tem e aprende a programar o micro. Vais ver q te surpreendes ao ver q afinal hais vida p alem do arduino.


Neste momento na historia, fora de um ambiente de educativo, nao sei se serah boa ideia apostar em AVR, ateh saber exactamente o q a Microchip tem na manga.
Grande parte da equipa da Atmel foi dispensada e nao ha noticias do futuro dos AVR. Fabricar vao continuar claro pois teem q honrar os compromissos de vida-util, mas novos desenvolvimentos c um core ja ultrapassado... hum nao sei. Pode ser q esteja errado.

[dio123]

No meu caso, já não uso arduino tudo feito em avr studio por mim,claro que vai os poucos mas vai. So fiz1 lib lcd e uart.
Agora até que ponto é que está de  fiar?
Código arrumadinho e o mais eficaz possível, economizar variáveis e o que tento fazer.

[Sérgio_Sena]

Entao pronto, o dia vai chegando em q tens q tomar a decisao de q o teu codigo estah estavel o suficiente p poder ser usado em servicos "nao-caseiros.

Certezas nunca as ha, mas se se usarem os perifericos de segurancao disponiveis no icro: Watchdog, BrownOut, ... , garantes q o teu down-time eh inexistente ou mt reduzido.

[KammutierSpule]

"fiabilidade" eh uma coisa que pode ter muitas ramificacoes.
Falaste de codigo, mas é imporante nao esquecer o hardware, mais concretamente: alimentacao (estavel) e proteccao de IOs. EMC, cristais, etc.
Variacoes/flutuacoes/etc no hardware podem colocar o MCU num estado indefinido (ou teres resets fantasmas) etc.

Depois disso, como aqui falaram, tens o watchdog. E' o mecanismo mais baixo nivel que podes usar de proteccao. so depois vem o codigo.

Hardware - > Watchdog -> Codigo

Na parte do codigo, como ja eh do dominio virtual, ha uma infindavel quantidade de opcoes e normas.

Uma das mais conhecidas (para sistemas embutidos) e'o MISRA C

https://en.wikipedia.org/wiki/MISRA_C

Da tambem uma olhada em
https://en.wikipedia.org/wiki/Test-driven_development
https://en.wikipedia.org/wiki/Static_program_analysis

Se fore codigos muito complexos, entao aplicar:
https://en.wikipedia.org/wiki/Software_design_pattern
que ajuda o desenvolvimento e debug.

Mas isto ja sao coisas mt avancadas.
Se for para um codigo "blink" simples, entao acho que basta seguires uma norma, aplicar algum software analise estatica.. e depois.. testar..testar..testar (testar extremos)

[dio123]

Ando aqui a tentar aprender o watchdog, mas nao estou a conseguir por exemplos a funcionar culpa minha ou culpa do isis proteus.  Devia ser numa board real mas tempo ainda nao houve.
O erro do proteus é PC=0X00FA[avr watchdog] timer expired processor will be reset

A ideia mais simples é: é dar um tempo para o codigo correr, por exemplo  8s e se ao fim de 8s nao for feito reset ao tempo ele faz reset. Isto é WDT System Reset mode.

Eu acho que se wdt_reset() ficar no fim do codigo ele numa vai fazer reset, se apagar wdt_reset() de 8 em 8 segundos faz reset certo?

#define F_CPU 16000000UL   
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#include <util/delay.h>

void blink_led(void);

int main (void)
{
   DDRB |= (1<<PB5);   // LED 13 cout
   DDRB |= (1<<PB4);   // LED 12 cout
   blink_led();
   wdt_enable(WDTO_8S);

   while(1){         {
      PORTB |= (1<<PB5);   
      _delay_ms(500);   
      PORTB &= ~(1<<PB5);   
      _delay_ms(500);   
      //wdt_reset();

}
}
void blink_led(){
         PORTB |= (1<<PB4);   
         _delay_ms(500);
         PORTB &= ~(1<<PB4);   
         _delay_ms(500);   
}

[jm_araujo]

Revê esse código para percebermos o problema, não deves estar com o  wdt_reset comentado como aí aparece, e tens aí uma função que não usas...

Edit:
E não sei que processador usas, mas ao ler o manual da biblioteca wdt.h reparei que há restrições de processador no  "WDTO_8S" : http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html. Confirma se estás na lista.

Sempre RTFM primeiro.

[Njay]

Pela mensagem o proteus está a dizer-te que o watchdog vai/está a expirar, que é exactamente como estás a usar isso. Provavelmente o proteus "não deixa" que se use o watchdog no modo "deixa-o expirar para fazer reset ao CPU", é o caso da ferramenta que só te deixa fazer as coisas "direitinhas".

[dio123]

Já esta a funcionar, mas no proteus não funciona com watchdog, pois fica em reset constante.
Estou a usar atmega328p e vi que estava na lista.

Aqui fica no novo codigo.

#define F_CPU 16000000UL   
#include <avr/io.h>
#include <avr/wdt.h>
#include <util/delay.h>

void blink_led(void);

int main (void)
{
   wdt_reset(); //reset watchdog timer
   wdt_disable(); //desligar watchdog timer
   MCUSR = 0;
   WDTCSR = (1 << WDCE) | (1 << WDE) ;  // Watchdog Timer configurado para  System Reset Mode
   WDTCSR = (1 << WDIE) | (1 << WDP1) ; // Watchdog Timer Prescale Select 8k 64ms
   DDRB |= (1<<PB1);   // LED 13 cout
   DDRB |= (1<<PB2);   // LED 12 cout
   blink_led();
   wdt_enable(WDTO_8S); // watchdog timer 8s

   while(1){         
      PORTB |= (1<<PB2);   
      _delay_ms(500);   
      PORTB &= ~(1<<PB2);   
      _delay_ms(500);   
      wdt_reset(); //reset watchdog timer
   }
}

void blink_led(){
         PORTB |= (1<<PB1);   
         _delay_ms(1000);   
         PORTB &= ~(1<<PB1);   
         _delay_ms(1000);
}

[Sérgio_Sena]

Larga o Simulador e investe num Emulador.

Por muito bom q o simulador possa ser, nunca te vai dar os mesmos resultados q o sistema fisico, pcbs, chips, ruido, temperatura, ESD, etc.

[dio123]

Partindo do exemplo do post anterior que funciona perfeitamente, assim como o meu codigo gsm que funciona bem. Quanto junto os 2 nao funciona. Fica um loop constante e nao sai dai,
Reparei que apagando a função sei(); o watchdog funciona mas o ISR (USART_RX_vect) nao funciona. 
Agora aqui nao estou conseguir resolver o problema.

agradeço.