Depends on the processor. For embedded devices like microcontrollers, the behavior is undefined, it may, or may not, return to the first instruction location. This is why each program should have an infinite loop, so as to keep the behavior deterministic.Just a quick question with a simple answer I hope. Does the void main() function continuously loop like the while(1) function does, or does it run through and then stop?
Simple main()function doesn't require a specific keyword or procedure for ending the program. In some programming languages, an END or EXIT command is required, but not in C. In the C language, the program ends when it encounters the last brace in the main() function. Hence in C main is not an infinite function. Wherein while(1) is an infinite loop.Just a quick question with a simple answer I hope. Does the void main() function continuously loop like the while(1) function does, or does it run through and then stop?
This is not necessarily the behavior in a non-hosted implementation, such as is often the case in embedded systems. See the earlier post by JohnInTX for a good description.Simple main()function doesn't require a specific keyword or procedure for ending the program. In some programming languages, an END or EXIT command is required, but not in C. In the C language, the program ends when it encounters the last brace in the main() function. Hence in C main is not an infinite function. Wherein while(1) is an infinite loop.
Hope that helped!
So by the well defined behavior (of this particular compiler) the start-up code is NOT run again if you drop out of the main() function.C18 User's Guide said:After the start-up code sets up the stack and optionally copies initialized data, it calls the main() function of the C program. There are no arguments passed to main(). MPLABC18 transfers control to main() via a looped call, i.e.:
Rich (BB code):loop: // Call the user's main routine main(); goto loop;
Looking at the question he posted I think it fits. He is not specifically asking about an embedded application. It is a general question so I gave general answer.This is not necessarily the behavior in a non-hosted implementation, such as is often the case in embedded systems. See the earlier post by JohnInTX for a good description.
Ah, no. A general answer would apply both to hosted and non-hosted applications.Looking at the question he posted I think it fits. He is not specifically asking about an embedded application. It is a general question so I gave general answer.
Welcome to AAC. You have replied to an old thread so it is unlikely the original TS is still looking for an answer.the problem is so simple ,,,, disable the watchdog counter ,,,, that is all
main() is a function, whereas while() is a statement. The two things are viewed differently by the compiler and ultimately the processor.Just a quick question with a simple answer I hope. Does the void main() function continuously loop like the while(1) function does, or does it run through and then stop?
Without a looping construct inside of the main() function it will return after executing the last statement before the closing curly brace. What happens next is compiler dependent. You have to locate and examine the C Startup file that is part of every embedded C program. From that assembly language file you can determine exactly what will happen. No general purpose answer will be accurate or reliable; you must dig (excavate(?)) for the answer.main() is a function, whereas while() is a statement. The two things are viewed differently by the compiler and ultimately the processor.
Not sure why you are replying to me. All I stated was that a function and a statement are different from one another, since the OP didn't seem to know this. Discussing entry points, stack frames, jump tables, and assembly language is well beyond what the OP needs at this point.Without a looping construct inside of the main() function it will return after executing the last statement before the closing curly brace. What happens next is compiler dependent. You have to locate and examine the C Startup file that is part of every embedded C program. From that assembly language file you can determine exactly what will happen. No general purpose answer will be accurate or reliable; you must dig (excavate(?)) for the answer.
This is precisely the case. I have had occasion to dissect several C startup files for about a dozen embedded processor/compiler combinations. IMHO the ones that do the best job actually force a hardware RESET by hook or by crook when there is a return from main. In most cases it is essential to draw as much attention to this behavior as possible. That said I can imagine a mission critical application in which a softer recovery mechanism might be employed. It is ALWAYS to the benefit of the embedded engineer to understand precisely what the canned compiler code is doing to(for) you. Only in that fashion can you inoculate yourself and your code.I don't think PB was so much replying TO you as much as just expanding on the information provided BY you -- and the point he is making is very relevant in a non-hosted environment, which if I recall (from three years ago) the TS was working with at the time.