SCOPE STACK OVERFLOW

You have done something wrong with your algorithm if you need 31 nested loops. Exactly what problem are you trying to solve that has so many nested loops?

When solving a problem that have an almost "unbound" number of variables and the algorithm should scan the full solution space, you don't do it by nesting loops. You do it by using data structures for the individual variables.

Think about a watch. It has hours and minutes and seconds. It loops 0..23 hours. Inside that it loops 0..59 hours. Inside that it loops 0..59 seconds. Just that there are not 3 nested loops. The code just looks like:

if (++seconds >= 60) {
    seconds = 0;
    if (++minutes >= 60) {
        minutes = 0;
        if (++hours >= 24) {
            hours = 0;
        }
    }
}

Above code still shows nesting - but as you can see, the code can be trivially rewritten:

overflow = false;
if (++seconds >= 60) {
    seconds = 0;
    overflow = TRUE;
}
if (overflow) {
    overflow = FALSE;
    if (++minutes >= 60) {
        minutes = 0;
        overflow = TRUE;
    }
}
if (overflow) {
    overflow = FALSE;
    if (++hours >= 24) {
        hours = 0;
        overflow = TRUE;
    }
}
if (overflow) {
    overflow = FALSE;
    if (++wdays >= 7) {
        wdays = 0;
        overflow = TRUE;
    }
}
if (overflow) {
    overflow = FALSE;
    ...
}

Suddenly, an infinite number of loops can be handled in sequence without nesting.

Obviously, the above code, if handling a really silly number of loop variables, can be rewritten even more, where there is just a table of n variables and n overflow + reset values, so you have:

#define NELEM(a) (sizeof(a)/sizeof(*(a)))
struct {
    unsigned val,restart,overflow;
} variables[] = {
    {0,0,60},  // seconds
    {0,0,60},  // minutes
    {0,0,24},  // hours
    {0,0,7},   // wdays
};
unsigned i;

for (i = 0; i < NELEM(variables); i++) {
    if (++variables[i].val < variables[i].overflow) {
        // No overflow, so no carry to next level of variables.
        break;
    } else {
        variables[i].val = variables[i].restart;
    }
}

You have done something wrong with your algorithm if you need 31 nested loops. Exactly what problem are you trying to solve that has so many nested loops?

When solving a problem that have an almost "unbound" number of variables and the algorithm should scan the full solution space, you don't do it by nesting loops. You do it by using data structures for the individual variables.

Think about a watch. It has hours and minutes and seconds. It loops 0..23 hours. Inside that it loops 0..59 hours. Inside that it loops 0..59 seconds. Just that there are not 3 nested loops. The code just looks like:

if (++seconds >= 60) {
    seconds = 0;
    if (++minutes >= 60) {
        minutes = 0;
        if (++hours >= 24) {
            hours = 0;
        }
    }
}

Above code still shows nesting - but as you can see, the code can be trivially rewritten:

overflow = false;
if (++seconds >= 60) {
    seconds = 0;
    overflow = TRUE;
}
if (overflow) {
    overflow = FALSE;
    if (++minutes >= 60) {
        minutes = 0;
        overflow = TRUE;
    }
}
if (overflow) {
    overflow = FALSE;
    if (++hours >= 24) {
        hours = 0;
        overflow = TRUE;
    }
}
if (overflow) {
    overflow = FALSE;
    if (++wdays >= 7) {
        wdays = 0;
        overflow = TRUE;
    }
}
if (overflow) {
    overflow = FALSE;
    ...
}

Suddenly, an infinite number of loops can be handled in sequence without nesting.

Obviously, the above code, if handling a really silly number of loop variables, can be rewritten even more, where there is just a table of n variables and n overflow + reset values, so you have:

#define NELEM(a) (sizeof(a)/sizeof(*(a)))
struct {
    unsigned val,restart,overflow;
} variables[] = {
    {0,0,60},  // seconds
    {0,0,60},  // minutes
    {0,0,24},  // hours
    {0,0,7},   // wdays
};
unsigned i;

for (i = 0; i < NELEM(variables); i++) {
    if (++variables[i].val < variables[i].overflow) {
        // No overflow, so no carry to next level of variables.
        break;
    } else {
        variables[i].val = variables[i].restart;
    }
}

THANKS for the details....
i'll modify my algo..... let u know afterwards..

You still haven't told us why you felt you had a need for such a huge number of nested loops.

spose u feel very clever?

give my m8 a break. hes just learning this stuff. u knew it all doin ur 1st project did u?

... feel very clever, but Per does not need to feel clever.

with that many nested loops the code IS messed up.

Of, course, it might be more politically correct to say "your excellent code has in your brilliance passed a silly limit set by the C standard. I do not know why the idiots that wrote the standard set a limit so low. Unfortunately, you will have to live with that limit ad reduce your loop count by the excess"

That, of course will leave the OP with code that, forever, is messed up.

A guy I know, refuse to look at code that, when correctly indented, has an identation level of more than 5. I think that is a good rule.

Erik

Data structures comes in very early.

But are you saying that beginners should not take one step back and consider "am I doing something wrong" when they get stuck by a compiler limitation, while thousands of professional developers do not get stuck by that same limitation?

spose u feel very clever?

Cleverer than you and your "m8"? Yes, obviously.

give my m8 a break. hes just learning this stuff. u knew it all doin ur 1st project did u?

Well, how come we don't see you helping your "m8", instead of whining about the quality of advice he got? If you really believe that you can help this guy better than earlier responders, how come your "m8" had to even ask here in the first place?

Here's a suggestion: How about you two get together off-line, and actually help each other? I suggest you ask him to teach you less atrocious spelling than yours, in return.

actully i m a fresher in an EMBEDDED job.... CURRENTLY I M WORKING IN A PROJECT WHERE IN THERE IS NEED OF MULTIFUNCTIONING OF 4 PUSH BUTTON SWITCH..... ALSO THERE IS A NEED IS TO LATCH THE CONTENT OF 7 SEG UNTIL NEXT BUTTON IS PRESSED OR UNTIL THE POWER IS OFF....THEREFORE THERE IS NEED OF WHILE(1) LOOP AT EACH STAGE... THERE IS NEED TO DISPLAYED SEVERAL NO.OF PAGES AT EACH PRESSED BUTTON... AT EACH STAGE ANY OF 4 BUTTON CAN BE PRESSED...

DON'T SHOUT!!

No, there is no inherent need of a while(1) loop at each stage!

I suggest you look into using a Finite State Machine (FSM) aka "Finite State Automaton" (plural: Automata) or just "State Machine"

www.8052.com/.../171492

www.8052.com/.../47505

State Machines for Event-Driven Systems
State machines are perhaps the most effective method for developing robust event-driven code for embedded systems."
by Miro Samek: www.netrino.com/.../State-Machines-Event-Driven-Systems

Coding State Machines in C and C++
"An overview of state-machine fundamentals and guidelines for coding state machines in C or C++."
by Miro Samek: www.netrino.com/.../Coding-State-Machines

This Whitepaper (with accompanying source code) gives a very good example of applying a State Machine design: www.visualgps.net/.../NMEAParser.html

Has moved to: www.barrgroup.com/.../Coding-State-Machines

Similarly: www.barrgroup.com/.../State-Machines-Event-Driven-Systems

So then there really was a good reason for me to ask you exactly why you thought you needed so very indented code.

for(;;) {
    key = check_keys();
    switch (state) {
        ...
        case STATE_MAINMENU:
            if (key == ENTER) {
                state = menuchoices[curr_menu_item];
            }
            break;
            ...
        case STATE_WAITINPUT:
            if (key == ESC) {
                state = STATE_MAINMENU:
            } else {
                ...
            }
            break;
        ...
    }
}

You want your main loop to iterate often, so it can check important global states. That means that the main loop should try to avoid to contain subroutines (or nested loops) that will take any significant amount of time.

We had someone do a firmware enhancement for us and he put in some finite state machines.

Trouble was he was so engrossed with them at the individual level that he neglected to include suitable protection (like task locking) on the interaction between them.

Careful. They are not the cure all. You still need good understanding of ALL aspects.

Good point.

There are no safe concepts that can't be abused by someone willing to try.

Good point.

Innnndeeeeeeeeedddddd.

ohh gud 1..... thanks a lot bro.... i'll try to modify the code...
ONCE AGAIN THANK U very much..