Thread: while(1)

  1. #1
    Registered User
    Join Date
    Apr 2012
    Posts
    37

    while(1)

    I know that for programmers of normal code, while(1) is anathema, and always avoid and never used.

    on the other hand for programmers of embedded systems it is almost always used in the following sense:

    It allows the system to "run forever" so as to permit that the embedded firmware wont stop

    However, I am being faced with a third option. I am (trying to ) maintaining some code I ve been handled and I found while(1) inside the code initialization function.

    For example:


    Code:
    PD.PDR.Reg=0x80;/* Output setting*/
    PD.PCR.Reg=0x6AAA;/* PD 7 Out 0-6 In */
    PJ.PDR.Reg=0xE0;/* Output setting */
    PJ.PCR.Reg=0x56AA;/* PJ 5-7 Out 0-4 In */
     
    PJ.PDR.BIT.P5DT =0;/* LED flashing */
    PJ.PDR.BIT.P6DT =0;
    PJ.PDR.BIT.P7DT =0;
    while(1){
             PD.PDR.BIT.P7DT =0;/* Buzzer */
                        }
    Now, for what I see there is some LED flashing done and then an infinite loop of a Buzzer sounding!!!

    Something obviously have to change because this code when executed is not buzzing for ever. Any idea what can make the code advance? At first I thought interruptions but interruptions would make me return to the same point I was interrupted right?

    Even Crazy, or any ideas welcome to understand what is going on

  2. #2
    Registered User
    Join Date
    Mar 2012
    Posts
    35
    Code:
    PD.PDR.BIT.P7DT =0;/* Buzzer */
    place this above while n leave while empty...

  3. #3
    Registered User hk_mp5kpdw's Avatar
    Join Date
    Jan 2002
    Location
    Northern Virginia/Washington DC Metropolitan Area
    Posts
    3,817
    Quote Originally Posted by KansaiRobot View Post
    I know that for programmers of normal code, while(1) is anathema, and always avoid and never used.
    Nonsense, there's nothing wrong with it at all.
    "Owners of dogs will have noticed that, if you provide them with food and water and shelter and affection, they will think you are god. Whereas owners of cats are compelled to realize that, if you provide them with food and water and shelter and affection, they draw the conclusion that they are gods."
    -Christopher Hitchens

  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    1) There is nothing "anathema" about while (1), regardless of whether programming an embedded system or not. It is discouraged by some style guides in favour of other loop constructs, but style guides are inherently subjective, so that is hardly the same as it being anathema.

    2) As to the code, there are various possible explanations. Generally, the explanation will involve some specific features of the target machine and maybe compiler extensions. Interrupts are only one possibility. There are two many other possibilities to guess. You will need to read up on the documentation for the code (if any), your compiler, the host operating system (if any), and the targeted hardware.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  5. #5
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    I have to agree here - there's nothing wrong with while(1), so long as you know what it does. (Personally, it would bug me that it's not while(TRUE), but I'm pedantic).

    As to how the code progresses? Well, if you've shown the entire loop then it's something outside the normal program. Maybe another thread, maybe a watchdog timer (hardware or software), maybe an OS kill of programs that are looping or timing out, all sorts of things.

    In embedded space, my bet would be watchdog timers. If you don't do action X every few seconds, the computer will reset and reinitialise. Usually action X is something like "write to a particular port or memory location". If the watchdog detects that it's been more than Y seconds since it was last "pinged", it initiates a reset. This can be an electronic circuit (so your port-probing is touching something physical on the board somewhere, independent of the main processor), or OS-control (i.e. the OS looks in between it's scheduling to see if you're probably "reset" the watchdog this time around and if not, kills your process and restarts it, or even just reboots the machine).

    Watchdogs are very common in embedded space and are basically an automatic reboot when something "jams" and the program isn't responding normally.

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  6. #6
    Registered User
    Join Date
    Mar 2011
    Posts
    546
    where in the standard C library is TRUE defined?

  7. #7
    Registered User
    Join Date
    May 2009
    Posts
    4,183
    Quote Originally Posted by dmh2000 View Post
    where in the standard C library is TRUE defined?
    Likely no where (in the standard libraries); IIRC, "true" is defined in stdbool.h.

    Tim S.
    "...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson

  8. #8
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    Not using C99? The latest "standard" for C?

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  9. #9
    Registered User
    Join Date
    May 2010
    Posts
    4,633
    Not using C99? The latest "standard" for C?
    Actually I use C11. The latest "standard" for C, don't you?

    Jim

  10. #10
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    I tend to use for(;;).
    while (1) can cause warnings about a conditional expression being constant.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  11. #11
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by ledow
    Not using C99? The latest "standard" for C?
    Like stahta01, I do not think that TRUE is defined in C99. You are probably thinking of the macro true.

    Quote Originally Posted by jimblumberg
    Actually I use C11. The latest "standard" for C, don't you?
    Someone go shoot the C standard committee. Their official website is so unclear on what the current version is ("The current C programming language standard ISO/IEC 9899 was adopted by ISO and IEC in 1999.") that I didn't notice until now that the update was in the news section. The C++ people have it right by blatantly listing the most recent version.

    Quote Originally Posted by iMalc
    I tend to use for(;;).
    Me too.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #12
    Registered User
    Join Date
    Apr 2012
    Posts
    37
    Wow, talk about fixating on a word that is not even important ("anathema", next time I ll use "excommunication")

    Anyway, I kinda found why of all these while(1)...

    They are some kinda of termination point, some kind of whirlpool to which the code goes and the program finish when certain conditions (related to hardware dip switches) are met. The only way is for the user to restart the program with a different combination in the dip switches.

    Wow
    Last edited by KansaiRobot; 04-18-2012 at 06:41 PM.

  13. #13
    Technical Lead QuantumPete's Avatar
    Join Date
    Aug 2007
    Location
    London, UK
    Posts
    894
    Quote Originally Posted by KansaiRobot View Post
    Wow, talk about fixating on a word that is not even important ("anathema", next time I ll use "excommunication")
    And you obviously haven't followed the conversation, there is nothing "anathema" or "excommunication" or "always avoid and never used" about while(1). You're making statements that just aren't true and people are calling you on that.
    "No-one else has reported this problem, you're either crazy or a liar" - Dogbert Technical Support
    "Have you tried turning it off and on again?" - The IT Crowd

  14. #14
    Registered User
    Join Date
    Apr 2012
    Posts
    37
    Quote Originally Posted by QuantumPete View Post
    And you obviously haven't followed the conversation, there is nothing "anathema" or "excommunication" or "always avoid and never used" about while(1). You're making statements that just aren't true and people are calling you on that.
    yes, and not answering the main question

  15. #15
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Quote Originally Posted by KansaiRobot View Post
    yes, and not answering the main question
    Actually, both grumpy in post #4 and ledow in post #5 gave you some hints and ideas as to what might be going on, basically that it was something outside the code. But both said it could be a lot of different things, and we didn't have enough info to give you a definitive answer.

    So, your main question was answered as best as possible with the information given. You never followed up with anything more, no hardware specs, no circuit diagrams, no more code. You gave us nothing else to help us help you more.

Popular pages Recent additions subscribe to a feed