PIC travando

[lpagano]

Pessoal,

Tenho um programinha aqui que é um cronômetro com PIC. Acontece que, durante a execução do programa está ocorrendo travamentos a qualquer momento, seja depois de alguns segundos, seja depois de várias horas ligado, ou seja, não tem hora para acontecer. Tenho que dar um reset para que volte ao normal. É o mesmo que o tal Ctrl+Alt+Del no Windows, mas aí eu perco o que fiz antes. O watchdog está desligado.

Já testei o programa tanto no 18F458 como no 16F877A e ambos travam, mesmo compilando em diferentes compiladores (CCS e MikroC).

Eu usei algumas vezes a instrução goto mas me disseram que essa instrução pode causar sérios problemas em C pois é um desvio incondicional.

Será que isso pode ser uma das causas dos travamentos?

Valeu!

[Cláudio]

Pra essas e outras que um ICD "da vida" é uma mão na roda... Com um pouco de trabalho, da pra saber certinho onde que o bixo trava... Depois que você tem um, se pergunta como sobreviveu sem um cara desses.
E sem ver seu código, fica difícil pra analisar...
De qualquer forma, como você mesmo sabe "goto" em linguagem C é totalmente desaconselhável.

[ze]

já é a 2ª reclamação do pic em menos de 1 dia! se continuar assim terei que avaliar outras alternativas de uC.
Sair de algo pico (10E-12) e ir pro [at]mega(10E+6). (talvez a atmel tenha colocado este nome propositalmente)

Pré condições:sua caixa preta não é + protótipo. Não tem gambiarra e aranhas e nem está no protoboard. Já está na pci final com todas as otimizações de layout. Seu sw é perfeito!!
vamos a algumas Conclusões Hipotéticas Universiais Técnicas Explicativas:
-cristal com problema (ou o lote) por acaso é de 32768? Verifique os caps. Troque por outra freq. (altere o sw claro)
-o uC come mal, ou seja alimentação suja
-ele está em cima de um gerador de Vandegraff. peguei pesado? foi de propósito. possíveis interf. externas.
Apelação: Deve existir algum atmel compatível pino a pino. (=PIC12XXX e xxHC908 alguma coisa). Se sim, seu fonte em C, moleza converter, então:
-Olá Atmel ou Frescale ou etc!!
Cara, acho que peguei pesado demais!! Ou não. São oportunidades para comparar as "sensibilidades" dos uCs concorrentes.
abrç

[lpagano]

Pessoal,

Refiz todo o programa, agora sem nenhum "goto", deixei ele rodando por horas e não travou. Acho que desta vez está ok, mas ainda vou deixar ele rodando por uns 2 dias ininterruptos para ter certeza.

Valeu!

[leocsbh007]

Pessoal,

Refiz todo o programa, agora sem nenhum "goto", deixei ele rodando por horas e não travou. Acho que desta vez está ok, mas ainda vou deixar ele rodando por uns 2 dias ininterruptos para ter certeza.

Valeu!

Fala cara, você faz tratamento de interruopção no seu codigo?
Se sim quando for atender desabilita e habilita antes de voltar para o programa principal, isto vai deixar seu codigo mais robusto...

att
leoCS

[andre_luis]

Um dos problemas do PIC é o tamanho limitado da sua pilha.

Se voce está programando em assembly, deve evitar o uso excessivo de CALL´s. Se está programando em ´C´, verifica se a RAM usada está próximo do limite.

Em todo o caso, só consegui perceber o estouro da pilha numa ocasião, somente depois da simulação com o MPLAB. Em tempo de compilação não foi gerado nenhum warning a respeito disso.

+++

[LeandroPIC]

nunca tive probremas com o goto em C, não é a intrução que trava o PIC mas como vc a usa!, o os AVR são mais sensiveis a ruido, o PIC é bem menhor que AVR si tratando de ruidos, mas acho que o PIC ainda supera um AVR em TUDO.

[Maurício]

Ô!!!!

[]'s

[phophollety]

Um dos problemas do PIC é o tamanho limitado da sua pilha.

Se voce está programando em assembly, deve evitar o uso excessivo de CALL´s. Se está programando em ´C´, verifica se a RAM usada está próximo do limite.

Em todo o caso, só consegui perceber o estouro da pilha numa ocasião, somente depois da simulação com o MPLAB. Em tempo de compilação não foi gerado nenhum warning a respeito disso.

+++

O MPlab não gera warning para isso, pq a pilha do pic é rotativa "First In - First Out"


e...


Goto em C? Que isso gente, não se faz isso não.. é crime!

[LeandroPIC]

Ô!!!!

[]'s

O que vc quis dizer com esse Ô, não intendi.

[mastk]

Pho, os PIC são limitados sim, não pelo FIFO da pilha, mas pelo tamanho dela ser muito pequeno, se não me falha a memoria 8 niveis, quando usa-va PIC tive problemas serios por causa disso, e a simulação do MPLAB, indica o stack overflow.

[phophollety]

Pho, os PIC são limitados sim, não pelo FIFO da pilha, mas pelo tamanho dela ser muito pequeno, se não me falha a memoria 8 niveis, quando usa-va PIC tive problemas serios por causa disso, e a simulação do MPLAB, indica o stack overflow.

Projeto com PIC16 eu estabeleço que nunca vou passar do 5 nível, pq se isso acontecer quer dizer que meu sistema tem tanta chamada que está amarrado demais e isto não é bom, pois sistemas reentrantes funcionam melhores, mais seguros e mais rápidos...

[lpagano]

Como estou usando um 18F458 no circuito, ele está usando 3% de ROM e uns 4% de RAM.

Só que, depois que eu acabei com os "goto" não travou mais.

Um amigo meu que é programador de C e C++ disse que não usa "goto" nos seus programas.

Não estou usando interrupções nesse programa, mas pretendo utilizar no futuro.

Valeu!

[phophollety]

Mas não se usa mesmo goto em C ou C++ (ainda mais se for em OO, java que é OO puro nem tem goto), pq goto é um desvio incondicional, ou seja, literalmente detona toda a sua estrutura de fw e para o compilador, não tem coisa pior...

Antes de fazer um programa, de uma rabiscada, veja que pode apenas chamando e retornando pelos métodos fazer tudo de uma maneira muito muito clara e limpa...

Se quiser, procure sobre POO (programação Orientanda a Objetos) e também UML

[]s