collapse

* Links de Robótica

* Posts Recentes

Palavras Cruzadas por Hugu
[Ontem às 00:54]


[Projecto] Bomba Airsoft por jm_araujo
[23 de Setembro de 2017, 16:54]


Apresentação por Tech_JA
[23 de Setembro de 2017, 09:19]


Medir Agua que está no Poço por filjoa
[21 de Setembro de 2017, 20:58]


URGENTE - display de 7 segmentos com backpack por helderjsd
[20 de Setembro de 2017, 12:30]


Preços e fabricantes de pcb por Sérgio_Sena
[19 de Setembro de 2017, 10:20]


Isaac Asimov - I, Robot por senso
[18 de Setembro de 2017, 03:41]


ic SL440 da Plessey? por senso
[16 de Setembro de 2017, 13:11]


Compra Colectiva RS-Amidata por brunus
[15 de Setembro de 2017, 22:31]


Ideias para construir um quadrúpede simples por zordlyon
[15 de Setembro de 2017, 10:18]

Autor Tópico: fiabilidade codigo.  (Lida 1728 vezes)

0 Membros e 1 Visitante estão a ver este tópico.

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 927
fiabilidade codigo.
« em: 24 de Abril de 2016, 23:57 »
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.                                       





Offline jm_araujo

  • Mini Robot
  • *
  • Mensagens: 2.126
  • NERD!
Re: fiabilidade codigo.
« Responder #1 em: 25 de Abril de 2016, 00:33 »
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.


Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.641
    • Electronic Gear for Musicians
Re: fiabilidade codigo.
« Responder #2 em: 25 de Abril de 2016, 08:31 »
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.

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 927
Re: fiabilidade codigo.
« Responder #3 em: 25 de Abril de 2016, 09:26 »
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.

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.641
    • Electronic Gear for Musicians
Re: fiabilidade codigo.
« Responder #4 em: 25 de Abril de 2016, 10:22 »
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.



Online KammutierSpule

  • Mini Robot
  • *
  • Mensagens: 1.123
Re: fiabilidade codigo.
« Responder #5 em: 25 de Abril de 2016, 14:03 »
"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)

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 927
Re: fiabilidade codigo.
« Responder #6 em: 15 de Maio de 2016, 22:20 »
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?

Citar
#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);   
}

Offline jm_araujo

  • Mini Robot
  • *
  • Mensagens: 2.126
  • NERD!
Re: fiabilidade codigo.
« Responder #7 em: 15 de Maio de 2016, 22:43 »
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.
« Última modificação: 15 de Maio de 2016, 22:46 por jm_araujo »

Offline Njay

  • Mini Robot
  • *
  • Mensagens: 3.088
    • Tróniquices
Re: fiabilidade codigo.
« Responder #8 em: 16 de Maio de 2016, 13:46 »
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".

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 927
Re: fiabilidade codigo.
« Responder #9 em: 16 de Maio de 2016, 13:56 »
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.

Citar
#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);
}

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.641
    • Electronic Gear for Musicians
Re: fiabilidade codigo.
« Responder #10 em: 17 de Maio de 2016, 10:56 »
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.


Offline dio123

  • Mini Robot
  • *
  • Mensagens: 927
Re: fiabilidade codigo.
« Responder #11 em: 12 de Junho de 2016, 17:41 »
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.