Programa Extenso

[Washburn]

Olá pessoal,

Estou escrevendo um código em linguagem assembly onde tem várias rotinas que se testadas separadamente funcionam bem, mas quando vou montando o programa com essas rotinas e começa a ficar extenso simplesmente o PIC faz algumas loucuras ou trava.

Alguem já teve este tipo de problema no inicio dos trabalhos com PIC?

[Rodrigo_P_A]

Olá pessoal,

Estou escrevendo um código em linguagem assembly onde tem várias rotinas que se testadas separadamente funcionam bem, mas quando vou montando o programa com essas rotinas e começa a ficar extenso simplesmente o PIC faz algumas loucuras ou trava.

Alguem já teve este tipo de problema no inicio dos trabalhos com PIC?

EU JÁ principalmente quando eu usava com o CCS heheh

[Washburn]

Pois é, mas estou usando MPLAB linguagem .asm

[vtrx]

Ja simulou com o SIM para seguir a ordem?
Pode ser alguma subrotina sua que esta mal configurada pois se esta em ASM voce pode seguir codigo a código para achar o erro.

[Andre_Cruz]

Use o MPLAB versão 8.43, que essa gera o arquivo com extensão COF *.cof.
Com esse arquivo você consegue simular linha a linha, no Proteus e assim você encontra onde esta travando.

Se estiver funcionando em protótipo, acenda um led quando entra em uma rotina e apague o mesmo led quando sair, ou escreva no LCD, assim é mais trabalhoso mas é possivel encontrar.

Abraço

[MOR_AL]

Washburn.

Quando o meu programa em assembler ficava grande, eu colocava um monte de "Pontos de Verificação".
Estes "Pontos de Verificação" são códigos que o programa envia para mim, quando ele passava por determinados endereços.
Se no meu circuito não havia LCD, eu introduzia uma saída com buzzer. Cada vez que o programa passava por um destes pontos, o buzzer era programado para enviar um código de um byte.
Por exemplo: Se entrou na rotina R1, então o código era 00000001, se entrou, ou saiu da rotina R20, então o código era 20 em binário.
O código binário era o seguinte:
Primeiro o bit mais significativo, até o menos significativo.
Se o bit era '0', então o buzzer durava 300ms, se '1', durava 900ms. Entre os bits, havia um período sem buzzer de 300ms. O byte ficava sendo repetido. Entre bytes havia um período de silêncio de 900ms.
Eu colocava um outro pino (de entrada) para o código parar de repetir e o programa ir adiante.
Normalmente eu não usava o pino de entrada. Apenas introduzia um bip, quando o programa passasse por um ponto que eu estava em dúvida. Quando este ponto fosse alcançado, eu alterava o programa. O bip tocaria no ponto seguinte.
Se o meu circuito possuia um LCD, então eu colocava o caractere que representava a passagem do programa por um ponto. Assim conseguia acompanhar o programa.
Claro que há outros métodos, este era simples e eficiente.
MOR_AL

[ze]

também há a opção de ao rodar o programa no mplab colocar break points em cada função (ou pontos estratégicos) . o F*** é se precisar de estímulos (tipo botões, ad, leds, etc). mas neste caso pode rodar no proteus e também usar break points (se carregar o .cof) . breack point: duplo clique na esquerda da linha desejada.
o analisador lógico do mplab também pode ajudar.
abç

[Vonnilmam]

Cara! Presta a atenção!!!!!!!!!!!!!!!!!!!!!!!!


Se vc tiver utilizando um PIC como por exemplo o F877A ou o F628A, oberservar que a PILHA destes ucs possui apenas 8 níveis...

Provavelmente o problema esteja na quantidade de CALLs que vc esteja utilizando, vale lembrar que um dos maiores problemas dos pics são justamente essa limitação "na minha opnião" ridicula de deixar só 8 niveis de pilha....

Se vc tem a rotina principal e chama uma subrotina através de um CALL, já consumiu 1 nivel na pilha (o nivel da pilha é responsavel pelo retorno da subrotina), aí se vc chama outra subrotina dentro desta rotina, já estão sendo consumidos dois niveis da pilha e assim sussecivamente até vc estourar a pilha e o processador ficar doidim...como diz meu amigo FABIM!

Então presta a atenção, faz a contagem do numero de calls que vc dá dentro de uma subrotina...ok

Outro fator a considerar pode ser a "PAGINAÇÂO", dá uma revisada e verifique se vc não errou nenhuma pagina, tipo: ao invés de chamar a pagina 3, vc chamou a pagina 4 e esqueceu de indicar na proxima linha o retorno a pagina origem, esse erro é muito comum, principalmente em programa grandes.

Outra coisa que pode causar erros é a seleção dos bancos de memória RAM, vai que vc efetuou algum calculo utilizando a RAM bank1,2 ou 3 e sem perceber foi testar algum resultado no bank0, aí poderá ter um erro inesperado também...

Minha dica é reanalizar cuidadozamente todas as subrotinas analizando esses pontos expostos acima, com certeza irá achar erros....

Em relação a simulação, eu particularmente utilizo o ICD2 pendurado no hardware projetado e vou simulando linha a linha ou bloco a bloco...

boa sorte

[Washburn]

Ja simulou com o SIM para seguir a ordem?
Pode ser alguma subrotina sua que esta mal configurada pois se esta em ASM voce pode seguir codigo a código para achar o erro.

Fiz isso sim e ajudou bastante...
Obrigado.

[Washburn]

Andre_Cruz e Mor_al,

Boa dica essa, tomei um tempo com muita paciencia e segui as dicas de voces, valeu a pena, praticamente ja resolvi tudo.

Obrigado.

Vonnilmam,

Legal essa observação, era um detalhe que estava bem mal observado no programa, após uma boa organizada no fluxo do programa melhorou muito.

Grato.

[Alesandro F Zagui]

Washburn

Existem algumas instruções especiais do compilador (Mplab), que poderiam te ajudar, como LCALL e LGOTO.
Esse L faz com que o compilador ajuste o PCLATH para saltos longos.

[lpagano]

Já tive um problema parecido, de travar o PIC, mas foi durante a execução de um programa feito em C na passagem por uma configuração de dispositivo I2C. Descobri isso do jeito que o MORAL disse, incluindo pontos de verificação no software.