Re: Select Case Weirdness
I'm thinking a case with no code in it is rather pointless (probably just confuses the compiler) and that includes thev "case else " too. what happens if you remove them
Re: Select Case Weirdness
Most likely problem is in DTMF receiver, not select case...
Re: Select Case Weirdness
Most likely problem is with code...
Think about it? How many digital lines come from the tone decoder that you are encoding? 4? Well that would equate to 0 - 15 combinations right? What you need to do is use the "data available" comming from the decoder as a qualifier for gating the case statement. Even if there are NO tones being decoded from the tone decoder there has to be some state the output lines are at right? Even if the output are "tristated" the input lines to the PIC when read will show some state. In other words, The NO CODE state is data NOT available....
Re: Select Case Weirdness
Quote:
Originally Posted by
richard
I'm thinking a case with no code in it is rather pointless (probably just confuses the compiler) and that includes thev "case else " too. what happens if you remove them
I agree with Richard.
Robert
Re: Select Case Weirdness
since we have only a code snippet to work with one does assume the routine is only called when there is a valid (dtmf decode ) data ready to analyse.
Re: Select Case Weirdness
OK, If thats the case,"routine is only called when there is a valid (dtmf decode ) data ready to analyse" then whats the problem?
Re: Select Case Weirdness
Pretty sure Richard is right. They were valid codes.
Quote:
Notice I put a "Pause 1000" into all the conditions that previously didn't have code - this line of code appears to stop this weird behavior from occurring
Re: Select Case Weirdness
Thanks for all the help guys - seriously appreciated! I found the error and yes indeed it wasn't with the select case at all. The cause: I was receiving a DTMF tone through a dedicated DTMF receiver IC which required a polling of a status pin which would trigger my code to shift out the tone value from the receiver IC in 4 bit format. Problem for me was that initially that value would be correct (as my debugging highlighted) and the select case was receiving this expected value (which my testing highlighted), but because there was no pause in the code anywhere for many tones, the code would go straight back to polling and receiving right after the select case execution which turned out to be too fast and the "tone value" register in the receiver IC must default to 15 after being read. Because the status pin still flagged a valid tone receive, my code would read this value (15) and act on it with the "select case" code in question and my output (a light globe for testing purposes) would only visibly display the result of the "15" value every time thereby leading me to erroneously assume the select case was causing the issue. Duh - apologies for any time wasted.
Thanks again,
Troy