ASM51

Bom pessoal, a principio eu acharia essa dúvida muito simples mas não sei mais o que fazer, não consigo desabilitar as interrupções que eu estou utilizando no meu programa.
O camando disable_interrupts(xxx) não funciona nem por "reza brába"...rs
Já tentei:

disable_interrupts(INT_TIMER0);
disable_interrupts(INT_TIMER1);
disable_interrupts(INT_TIMER3);

E nada de funcionar...
Não domino os PICs 18F e eles têm aquelas histórias de interrupções de alta e baixa prioridade no hardware, como eu trato isso?
Já revirei o livro do Fábio (Programando em C) e não achei nada diferente desses comandos acima.
Eu quero dentro de uma interrupção desabilitá-la até que um evento a habilite novamente, têm problema fazer isso?
No 16F877A existe uma chave de periféricos PEIE, nesse existe algo parecido?
Muito obrigado!!!

Olá Fabio,

Você pode desabilitar as interrupções através dos registradores INTCON, INTCON2 e INTCON3. O bit PEIE está localizado no registrador INTCON.

A maioria dos periféricos podem ter suas interrupções individualmente habilitadas através dos registradores PIE1 e PIE2.

Consulte o datasheet do componente ...

T+

Puxa, nada melhor que receber a resposta do próprio autor do livro...
Mas Fábio, porque eu usando o disable_interrupts(XXX) não desabilita a maldita interrupção (ontem gastei umas 5 horas em cima disso), fiz tudo que eu pude/sabia e nada daquela praga funcionar, olha um trecho do código:

// Nesse trecho eu defino quando vai ocorrer a primeira interrupção (iDentes = lDentes_Ligado) Timer3 e garanto que bbobina estará em 0...

if (iDentes == lDentes_Liga)
{
enable_interrupts(INT_TIMER3);
set_timer3(lTempo_Estouro);
bbobina = 0;
}

// Daí a interrupção vai acontecer duas vezes, gerando um pulso de largura definida

#inline
void trata_t3()
{
t3if = 0;

if (bbobina == 0) // gera a borda de subida já que bbobina vai ser 0
{
bbobina = 1;
set_timer3(45000);
}
else
{
bbobina = 0; //gera a borda de descida finalizando o pulso
disable_interrupts(INT_TIMER3); //TMR3IE=0;
}
}


E só depois de um novo evento específico volta a ocorrer a primeira rotina, ou seja, enquanto não ocorre esse evento singular não deveria existir pulso, no entanto fica lá o pulso no Proteus 7.
Não sei se é pau do CCS, se é pau do Proteus, se estou usando o comando erroneamente...
O fato é que eu não quero desabilitar as outras interrupções que devem continuar acontecendo, uma de TIMER0 e outra de CCP2.
Muito obrigado pela ajuda Fábio, mas infelizmente permanece minha dúvida, eu vi que o código em assembly para o disable_interrupts(XXX) limpa o flag que habilita a interrupção por overflow do TIMER3, não é só isso que deveria ser feito???
O único jeito que eu consegui parar a interrupção foi desconfigurando o timer...

Fabio_Jerena escreveu:...porque eu usando o disable_interrupts(XXX) não desabilita...

Porque o CCS não presta! no PIC 18 vc pode usar o C18 ou o Hitech, muito mais proficional,e os comandos funcionan...

Amigo, agradeço sua sugestão mas infelizmente esse projeto para o meu nível é bem complexo, o programa está grande e eu tenho certa urgência em finalizá-lo, não terei tempo útil para migrá-lo integralmente, o CCS eu aprendi sozinho usando o livro do Fábio, já o C18 vou conhecê-lo na faculdade daí com certeza nos meus próximos programas poderei iniciar utilizando esses compiladores sugeridos...
Esse é o meu medo quanto ao CCS, não sei se sou eu que estou comendo bola ou se é bug do programa, ouço muitas pessoas falando mal, por isso estou buscando ajuda aqui!!!

já usei o CCS, muitos comandos não funcionavam comigo tambem... ai o que eu fazia era fazer uma chama em ASM e configurar os registradores diretamente "AI FUMFA NA MARRA".

Olá Fabio,

Bom, eu acho que a melhor solução é manipular os registradores diretamente e não utilizar funções prontas. Tenho certeza de que se você apagar o bit TMR3IE do registrador PIE2, a interrupção do TMR3 não vai mais acontecer.

No mais, utiliza as funções prontas do compilador quem quer. Há muito tempo que eu digo aqui no fórum que se você quiser ter controle absoluto sobre o que está acontecendo, então é melhor manipular os registradores do chip diretamente.

T+

Bom, então fico feliz de saber que eu não sou tão burro assim... Ou o Proteus não presta ou o CCS não compila direito, não é possível acontecer isso:

#byte pie2 = 0xFA0

#bit TMR3IE = pie2.1

E no programa eu fazia:

TMR3IE=0;

que é a mesma coisa que:

disable_interrupts(INT_TIMER3);

E a interrupção não para, simplesmente não para!!!

Consigo fazer parar quando desligo o PEIE, mas por consequencia me ferra o sistema já que trabalho com outras 3 interrupções...

Bom, concluí que nada concluí e que de certa forma não devo confiar na dupla CCS+Proteus, o difícil vai serarrumar um analisador lógico na vida real para realizar os meus testes de temporização!!!
Simplesmente bizarro e desmotivante!!!

Mesmo assim Fábio, agradeço sua ajuda, duro foi ligar para a Labtools e eles falarem que os trechos não possuem erro de lógica, me mandaram consultar o seu livro e eu fiz igualzinho ao que ele propõe...

Vou desmontar o programa e tentar testar por trechos, quem sabe não é alguma loucura nesse meio!

Abraço

Fábio, no CCS tem a função clear_interrupt(xxxx), outra coisa, use o MPLAB pra simular o prg e veja se ele está mudando os bits do registrador corretamente, é a forma mais fácil de verificar isso, qualquer coisa estamos ai.

Orcino

Pois é Fábio,

Por isso eu gosto dos HCS08: o BDM está a anos-luz de distância do ICD em termos de depuração.

No mais, creio que você terá de utilizar a boa e velha técnica de mudar estado de pino e ler com o osciloscópio ...

T+

Estou desconfiado que o problema está na velocidade, o programa está rápido demais, faça alguns testes "intercalando" com DELAY's, já tive vários problemas com relação a interrupção e velocidade de processamento (clock), delay's resolveram o meu problema.

Muita gente critica o CCS, utilizo-o faz um tempão, crio programas monstruósos com diversos modelos de PIC's da Microchip, até hoje nunca tive algum problema INSOLUCIONÁVEL, sei que existem compiladores melhores, mais flexíveis ao programador, más "C CCS" é Show de Bola também, principalmente para iniciantes...

Boa sorte,

Paulo
ppap@translate.com.br

Bom pessoal, que a justiça seja feita, até o presente momento não tive nenhum problema com o CCS que não fosse eu o causador, com esse não foi diferente...
O programa possuía uma rotina de tratamento de interrupções feitas em Assembly para agilizar o tratamento, baseia-se em testar os flags de interrupção dos periféricos e tratá-los de acordo com a ordem de chegada, como esse evento era o mais importante para mim eu o coloquei como o primeiro da lista, então o problema começou quando eu desligava a interrupção de overflow do Timer3 mas não o parava, então ele estourava e setava o flag de estouro, no entanto , quando outro evento gerava uma interrupção ao testá-las ele automaticamente tratava a interrupção de Timer3 pois o flag estava setado mesmo ela estando desabilitada (ou seja, não era este evento que remetia ao tratamento da interrupção). Depois que parei o timer3 junto com o flag que desabilita a interrupção tudo passou a funcionar muito bem obrigado, daí achei outros erros e ainda estou desenvolvendo o programa!
Relatei isso pois muitas vezes estou sendo injusto com um software sendo que quem está comendo bola sou eu...
Como não conheço outras ferramentas vou trabalhando com essa, quem sabe vou migrar para o C18, ouço falar muito bem dele, melhor que o próprio CCS.
Muito obrigado a todos que me ajudaram, especialmente o autor do livro, que alem da ótima literatura ainda deu um suporte, muito obrigado Fábio!!!