ASM51

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!

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.

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ç

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!

lpagano escreveu: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

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.

+++

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.

Ô!!!!

[]'s

andre_teprom escreveu: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!

Maurício escreveu:Ô!!!!

[]'s

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

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.

mastk escreveu: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...

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!

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