condition is. i used timer interrupt and call it in every 50 ms or something, then after all conditions and situations it comes to an point where i want that my loop will end and start main program from where i want to start.

but whenever i call that main function loop (the function i m calling from main during interrupt on going) it remains in interrupt routine but working as main (like endless interrupt loop) beacuse the function i'm calling is endless in main. and coz of this i can't call another interrupt.

Please provide a minimal code example that can be compiled and provide more detail on what you want the code to accomplish.

Typically, you do not want to call any functions from within an ISR. Just set a flag within the ISR and then on return from the ISR let the main loop take action based upon the flag being set (or not).

Seems like you want to do some bad juju. You REALLY don't want the isr to swap tasks. The 'usual' technique for handling pushbuttons is to use a regular timer interrupt (this looks like you're doing already) but looking at your code snippet, you're reloading TCNT - use the timer CTC mode where the hardware does it for you. In the timer tick isr, you debounce your pushbuttons and put the key presses into a FIFO buffer. You main() code can then read keypresses from the FIFO buffer and process them.

By the way, this is what it looks like when you use the code button that looks like "<>"!

As a side note on code execution, you say that you want button pushes processed instantaneously. Yet, the button state is checked only once every 50ms. To me, that sounds like a contradiction. You can check and process a button with your code, and if a button is pushed immediately after the ISR executes, there is still another 50ms until the next time it is checked. That is hardly a recipe for "instantaneous". Besides, human users can barely detect anything faster than 100ms, so 50ms is instantaneous enough for me. Further, the main loop will surely take far less than 50ms to loop, each time. So, the main loop will NOT be the response limiter.

Yes they did....but not much.... I'll show you my full code please tell how to improve them and how can I do it another or best way......but I'll be able to share after some time because right now I don't have the codes I've to rewrite them unfortunately.

Here if he presses a key he has to wait for the calendar to change before its acted upon. Therefore he tries to process the key in his IRQ.

??? You are losing me. Are you referring to the "could take 100 ms"?

You still need to keep your head about you. You [real people] don't sit in one place for 100ms. You generally don't even care about "key down" -- periodically, the states of the inputs are gathered, and entered into the debounce mechanism. The mechanism grinds up the new states from the input hopper when the handle is cranked. In the output hopper appears the confirmed/debounced states. If you have the deluxe model mechanism, then the machine's output also provides you with rising and falling edges, and duration information for inputs held in a certain state.

N.Winterbottom wrote:

...if he presses a key...

In general, "he" >>has not<< 'pressed a key' when you see keydown. It is only important when it is confirmed.

OP hasn't given us any hint on why things need to be done "without delay", and what is considered no delay. If indeed you are processing high-speed encoder edges, then you need to get ready for the next edge within microseconds and the edges must be clean. No debounce mechanism.

If the switch in question causes a nuclear missile launch when pressed, do you want to launch that missle "without delay" when you see a noise spike, or do you want to wait for a confirmed-good change of state?

If you have a big wall-mounted mushroom-headed e-stop button, then you need a monster debounce -- that is the only device in my experience where 4x 10ms wasn't enough.

Nearly all other cases fall between, and you are always 'behind' by the debounce time. It rarely matters.

One can construct hybrid mechanisms that 'guess' at what the state will probably be after debounce. Example: An app mostly sleeping waiting for inputs to change, and when they do, send a wireless message. Intruder alert? Like that.

So when you see the "key down" you awaken. The radio warmup time might well be as long as the debounce interval, so you start warming it up, guessing that the change of input state will be confirmed.

If confirmed, send the message and proceeed as normal. If not confirmed, shut everything down and go back to sleep.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Please help me with above program, whenever counta|b|c|d any of them goes high i.e above 7, my firstlogiccycle starts but in the end when it completes fourthlogiccycle i want it to go at first logic cycle again but not wanted to remain in interrupt routine. it comes out of routine but after 8 or 10 sec(I don't know why).

See post #13 for suggestions. Don't run your functions from the timer isr directly. You do realise that your code really doesn't mean too much to us - there's no comments and how do we know what it is supposed to do? Also, go back and format your code using the <> button on the toolbar - this makes it easier for everyone to read.

but in this case i just need to know in last at fourth logic cycle i m using cli(); and calling firstcycle() it remains in ISR for some time how to overcome from that.

I just explained that your code will eventually cause stack overflow. Don't you think this is quite serious? Maybe you should fix that? Maybe that is part of the solution to your issue you are seeing ("it remains in ISR for some time")?

I'm too lazy to write a tutorial - plus it's a lovely sunny bank holiday and I'm not going to spend it in front of the computer.

You need to research maintaining a system timer tick - chain other timer variables from that and use them to replace your delays. This can speed up the cycle time of your mainloop.

Learn about a state machine at its simplest level. I.e. The actions of a function depend on the value of a state variable which you modify to cause a different action to occur next time the function is called. a switch-case is commonly used for this programming pattern.

Set a boolean in your ISR and defer the handling of the PINA changes to the mainloop, which will now be fast enough for good responsiveness.

I just explained that your code will eventually cause stack overflow. Don't you think this is quite serious? Maybe you should fix that? Maybe that is part of the solution to your issue you are seeing ("it remains in ISR for some time")?