wanted to start a thread to see the proper way of using the tmr interrupts so they wont effect the loop....first off the compiler complains when i enable a tmr interrupt then disable it, how can i get around this? how can the tmr be used and not effect the loop(jitter) ....how many tmr interrupts would be acceptable to use as a max number per chip? .... if setting one up at 1k what should i set the other ones to so there is no conflicts of missing events? and stuff like that!.... basicly i've been using port,int,tmr0,1,2 interrupts for months now and want to see where the loop holes are in my designs and where i should stay clear for PROPER USE OF TMR0,1,2
Re: tmr interrupts
Posted: Mon Mar 12, 2012 10:13 am
by Benj
Hello,
first off the compiler complains when i enable a tmr interrupt then disable it
Is this the warning about re-enabling the macro using a different Flowcode macro? If so then this is simply saying that if you re-enable the interrupt using a different Flowcode macro then only the first macro you selected will get called.
If two interrupts are triggered at once then one will be serviced followed by the other. You shouldn't miss any interrupts unless one is triggered while in a disabled state.
Re: tmr interrupts
Posted: Mon Mar 12, 2012 11:20 am
by medelec35
Benj wrote:You shouldn't miss any interrupts unless one is triggered while in a disabled state.
Hi Ben, It is my understanding that if an interrupt is triggered while in disable state its placed in a type of queue, then as soon as interrupt is re-enabled then the interrupt in the queue is then instantly triggered.
Would you mind clarifying that for me please?
Re: tmr interrupts
Posted: Mon Mar 12, 2012 11:40 am
by Benj
Hello,
Each interrupt is generally governed by an interrupt enable flag and an interrupt pending flag.
The interrupt enable flag is controlled using the Flowcode interrupt icons.
The interrupt pending flag is controlled by the peripheral, eg timer timeout or UART byte received.
It is my understanding that if an interrupt is triggered while in disable state its placed in a type of queue, then as soon as interrupt is re-enabled then the interrupt in the queue is then instantly triggered.
This is correct but as there is only one pending flag you only get the one interrupt being stored while the interrupt itself is disabled. If the pending flag gets reset eg during the re-enable process then this could cause an interrupt to be missed after it has been re-enabled.
Re: tmr interrupts
Posted: Mon Mar 12, 2012 12:03 pm
by medelec35
Thanks for clarification Ben.
Martin
Re: tmr interrupts
Posted: Mon Mar 12, 2012 8:46 pm
by brandonb
Is this the warning about re-enabling the macro using a different Flowcode macro? If so then this is simply saying that if you re-enable the interrupt using a different Flowcode macro then only the first macro you selected will get called.
i dont understand this? what i was hoping to do somehow is enable a tmro interrupt only when the switches are pressed then disable when switches are not pressed because the program im using while the tmr is active it makes the output jitter.... is it possible to do this?
Re: tmr interrupts
Posted: Thu Mar 22, 2012 4:33 am
by brandonb
something im curious about--> if im using 3 tmr0,1,2 (all three timers) and i set them all to 61 hz i dont see how this could work since all three would be running through macro at the same time but program could only process one, am i missing anything, what would be the correct way of doing this? and reasoning behind it
Re: tmr interrupts
Posted: Thu Mar 22, 2012 1:27 pm
by Benj
Hello,
On a 8-bit PIC using multiple interrupts without priority settings you basically service each interrupt as it requests attention. eg if timer 0, 1 and 2 all interrupted at exactly the same time then the code would service timer 0, followed by timer 1 and finishing with timer 2. Otherwise the timer that interrupted first would be serviced first.
Some chips allow you to prioritise the interrupts allowing you to control which interrupts are more important and require servicing first.
Re: tmr interrupts
Posted: Thu Mar 22, 2012 5:48 pm
by brandonb
thanks ben, to clearify, no matter what frequencies i use i will never mis a timer based interrupt, why would this happen in a nutshell?.....what about port or int interrupts, so if i have 3 timers going at same or different frequecies and have a couple port interrupts at the same time what would happen here? ..... is there any write ups that explain how all this works, i would like to understand it so i dont get my self in trouble
Re: tmr interrupts
Posted: Fri Mar 23, 2012 12:35 pm
by Benj
Hello,
The only time you might miss a timer interrupt is if you are still executing code in the service macro when the next interrupt occurs. That is why it is common practice to get out of the service macro as quickly as possible and execute as much of the code as possible as part of the main.
You should be fine really, have a play with the interrupts and see what's possible. I have created programs using timer and signal based interrupts all tightly interwoven around each other for my propeller display and not really experienced any significant problems.
[/youtube]
Flickering is only picked up by camera. to the eye you get a static image. Flickering is good to show how its working, only ever 1 segment on at a time.