The break; statement - A 'D'oh' moment!

[neil]

Hello, I've been tearing my hair out over this. my code was working fine, then I simplified it, as in removed all the unnecessary bits and suddenly the processor hangs. A familiar thing I'm sure!

I eventually traced the cause to a 'break' statement in my string decode routine (receiving buffered data over RS232, then working on a received string). I had removed a bit test which I had bracketing the whole function, but did not remove a break statement I had inside these brackets.
This would have broken out of my main "while(true){ ....}" loop. I guess this would cause the processor to run off into unprogrammed code space. I am using a bootloader which doesn't fill the unused space with 3FF either, so the results would be really screwy, depending on what I had programmed in there last!

I would have hoped the compiler would warn of this. I don't know if it does in standard C, but I have never experienced this before. So, lesson learnt!! Something to check for when weird things start happening

A code snip for those still reading...

[Mark]

It should break out of the while(true) loop and then hit the hidden sleep instruction that CCS places at the end of main.


Now from the two code snippets, I don't see how either of them are correct. None break out of a loop in the code snippet.

[neil]

Hi Mark, yes, after looking at it again I can't see a problem. The symptoms I was seeing were like a sleep. It just stopped responding to anything. I should have thought of scoping the osc. pins to look for a clock!

I never use any sort of version control during development, only after 'release', so the version which wasn't working is now overwritten

I know this is *really* fundamental C, which I should know like the back of my hand, but does the 'break' break from the if(RX_string..) parentheses which it is in, or does it break from the parentheses immediately after "str_ptr++;" I would expect the latter (and no further).

I think I must have done something like delete a bracket by mistake which happens to line up with another previously deleted (unrelated) bracket, so the compiler doesn't trap an error, but the code does unexpected things.
_______________

About the comments on KupiKupi's post on IR remote decoding.... That MikeValencia wants his butt kicking for those comments! It's a good job people like you are willing to devote enough of their spare time to help others, and give them confidence no matter how trivial their problems! I would have struggled with that project though, so I wouldn't call that trivial.
Personally I think his lecturer is the one who should give up. When I was at University I had a few useless lecturers like that and I feel for him!

Please don't think of ever leaving this forum!

Neil.

[Ttelmah]

A break statement, does not break out of 'if' statements at all. It breaks out of the last loop control, or switch. The statements that a break will exit, are:
Do, while, for, and switch.
Remember you can also use 'continue', which causes a loop 'back' to any of these same statements, and causes the next 'retry' on these.

Best Wishes

[neil]

That explains a lot! I had completely misunderstood the syntax! It was in fact breaking out of the main loop and hitting sleep. Looking back at Mark's post this is exactly what he meant (I misunderstood this as well). The odd thing still is that It was working before with this break statement, although now I don't see how it possibly could.

Anyway, I've just put Kernighan & Ritchie's reference book on order. I used to have a copy and leant it to someone... You know the rest!

Thanks both for your help. What would I do without you?... No don't answer that