Select Case Weirdness

[rocket_troy]

PIC18F14K50 processor
PBP Program to receive a DTMF tone from a dedicated tone receiver chip and to process various stuff depending on the tone received.

So, I check for valid tone receipt and all that... and place the received tone into a variable called ToneIn once one comes through. From there I use a "Select Case" condition to perform various tasks depending on the value of the tone - there's 16 available DTMF tones.

Here's the Select Case part of the code:


'************************************************* *******
Act_On_Tone:
'************************************************* *******

Pause 100

'Main Case condition for each various tone received
select Case ToneIN
case 0 'DTMF D
Pause 1000
case 1 'DTMF 1
Pause 1000
case 2 'DTMF 2
Pause 1000
case 3 'DTMF 3
Pause 1000
case 4 'DTMF 4
Pause 1000
case 5 'DTMF 5
Pause 1000
case 6 'DTMF 6
Pause 1000
case 7 'DTMF 7
'Arm Flight Computer
FC_Arm = 0
Pause 500
FC_Arm = 1

case 8 'DTMF 8
'Report back (audibly) the Pressure Sensor Status
Pause 2000
PTT = 0
Pause 200
if sensor1 = 0 then
sound Audio_Out,[100,50]
'FREQOUT PORTC.1,1000,1000
else
'FREQOUT Audio_Out,1000,2000
sound Audio_Out,[100,50]
Pause 500
'FREQOUT Audio_Out,1000,2000
sound Audio_Out,[100,50]
Pause 500
'FREQOUT Audio_Out,1000,2000
sound Audio_Out,[100,50]
endif
PTT = 1

case 9 'DTMF 9
Pause 1000
case 10 'DTMF 0
Pause 1000
case 11 'DTMF *
Pause 1000
case 12 'DTMF #
Pause 1000
case 13 'DTMF A
Pause 1000
case 14 'DTMF B
'Activate Channel 1 for 2 sec
Ch1_Out = 1
Pause 2000
Ch1_Out = 0
case 15 'DTMF C
'Activate Channel 2 for 3 sec
Ch2_Out = 1
Pause 3000
Ch2_Out = 0
CASE else

end select

Return

Now here's the weird bit: if the incoming tone value matches a CASE condition with code in it, it'll run that bit of code and all is sweet. If the incoming tone value doesn't match a CASE condition with any code in it, the case condition for "15" is assumed and that section of code is executed for condition ToneIn=15. 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 ie. the code for ToneIn=15 won't execute if tones 1,2,3,4,5,6,9,*,#,A are received. Remove that "Pause 1000" line and the ToneIn=15 condition is somehow executed for all those other tone values.

Any clues?

Thanks

Troy

[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

[pedja089]

Most likely problem is in DTMF receiver, not select case...

[Dave]

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....

[Demon]

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

[richard]

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.

[Dave]

OK, If thats the case,"routine is only called when there is a valid (dtmf decode ) data ready to analyse" then whats the problem?

[Demon]

Pretty sure Richard is right. They were valid codes.


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

[rocket_troy]

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