use of Timer1 and portA interrupts together

[Darrel Taylor]

Did you add IF tests for all the interrupts you are using? (IOC and INT)
Are you sure you want to use INT? The INT pin is also an IOC pin.

For a 4Mhz crystal, you would use the XT oscillator mode.
The oscillator mode has no effect on IOC interrupts.
And whether it's internal or external, as long as the OSC is 4mhz, it has no effect on the Timer interrupts either.

[Alexey]

Hello Darrel,

Yes, I already learnt that interrupts require a great attention and careful programming Sometimes I could not understand why I am getting different results with (on my opinion) same approach but probably just one little thing outside of my attention makes all difference. I just noticed that simple use of SLEEP in a branch that is not executed when my TIMER1 is used does not allow timer to work Simple commenting SLEEP in that branch restores work of the TIMER1. Not sure why. Maybe if I use sleep, PICBASIC reserves the timer1 for it, although I thought it uses TIMER0 (will look how WDT affects this - maybe I had it disabled - will check)
I use interrupt on change on PORTA.5 and RA2/INT on PORTA.2 which helps to filter when A.2 button pressed and when I have signal on A.5 Yes, I do use IFs to handle interrupts

Oh... how many things I need to learn...

Thank you for help!

[Darrel Taylor]

When a PIC goes to sleep, the primary oscillator is shut down.
Since Timer1 gets it's clock from the primaray oscillator, it stops too.

Timer1 can run on an external 32768hz crystal while the PIC is asleep.

[Alexey]

Thanks Darrel,

I am getting crazy with these things... Now I have interrupts from timer working until I call a subroutine. Tried to remove everything from the subroutinemaking it like this:

gosub test

[mister_e]

That snip is not going to help a lot Would be better to post your whole thing.

[Alexey]

Hello Steve,

It looks like the problem was not in the code itself oir not only in code. I do not know for sure where are my mistakes and where are software glitches. Some time ago I contacted Melabs support that my USB programmer programs something wrong and one of the ports I use do not work. (I programmed a batch of chips, soldered and sealed them and they all were bad. Same code programmed by ICD3 was good. I was advised to reset the programmer to factory defaults which I did and it helped. This time I am suffering from unstabile results and really started nervous because I could make a change in a good code, then reverce the change and the code no longer worked. Finally I read my just programmed MCU (programmed using Melabs USB programmer) then read it using Picstart plus and learnt that instead of INTOSCIO it was configured for external clock! (Although it was for sure IUNTOSCIO at the time of programming) Chnging the setting and rerecording the code back into the same MCU (now using Picstart plus) gave a working MCU. Resetting programmer into defaults fixed the problem, but I know for sure that it was in the defaults before. Also I have some screenshots where Melabs programmer says verification ok, then I read the MCU (with same Melabs programmer) and it is empty. Resetting to defaults (which was already reset some time ago change fixed the problem). I have a styrong feeling that I am not going to use that programmer any more as I do not want to reset it every time before programming...

Now I hope that if I change programmer (both hardware and software to Microchip ones) I will have to fight only my mistakes, and all glitches I had were related only to the programmer, not to compiler or assembler...

regards,

Alexey

[mister_e]

I never experimented many weird compiler behaviour since I use PicBasic Pro myself, and I use it since over 10 years. Most of the time I got Error Code #18 to #24... which are located 'round 18 to 24 inches behind the keyboard

I can't comment Melabs programmer I don't have it, but I do have PicStart Plus & PicKit 2 (and others). Both gave and still give me good results.. But yeah, I heard a lot of weird programmer behaviour here and there.