ASM51

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?

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

Pois é, mas estou usando MPLAB linguagem .asm

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.

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

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

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ç

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

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

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.

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.

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.