CASE and ABORT

eagletalontim

I am not finding much information about the CASE statement and was wondering if using ABORT will "break" out of the CASE and process lines past it. Example below :

case myVal
  1:
    ' do some stuff
  2:
    if(anotherVariable == BadCondition)
      ABORT
    ' do some stuff here
  3:
    ' and do some other stuff here

' start processing here if case is finished or "aborted"
outa[myPin] := new_state

eagletalontim

I just remembered about the QUIT command....

Since my case is in the "MAIN" loop, I don't want it to quit the REPEAT. Will using the QUIT command in a CASE only leave the CASE and continue the REPEAT?

Dave Hein

ABORT works like return, but will return from all callers until it hits the abort trap "\".

QUIT can only be used within a repeat, and will exit the repeat loop.

You could use NEXT if you want to skip the rest of the loop, and execute the next loop iteration.

What you should do is this:

  2:
    if anotherVariable <> BadCondtion
      'do some stuff here

Mike Green

QUIT will exit the REPEAT (read the description in the manual). NEXT will go back to the beginning of the REPEAT loop. Usually what I've done in this circumstance is to move the CASE into a PRI method and use RETURN to exit back to the REPEAT code. You can use the RETURN to return a TRUE / FALSE code that causes a QUIT to be done

eagletalontim

I could do it that way, but I was worried about other code taking too long to be processed while the device has detected a "bad condition" for the specified CASE number. If the bad condition is met, a variable need to be changed, then the CASE needs to exit, process the new change, then repeat back to checking the case...

PUB Main
repeat
  case myVal
    1:
      if(anotherVariable == BadCondition)
        myVal := 2 ' change myVal to 2 but don't change to the next case "2" until other code has run below CASE
        NEXT ???
      ' do some stuff including check external IC data, and other time consuming processes
    2:
      if(anotherVariable == BadCondition)
        myVal := 3 ' change myVal to 3 but don't change to the next case "3" until other code has run below CASE
        NEXT ???
      ' do some stuff including check external IC data, and other time consuming processes
    3:
      if(anotherVariable == BadCondition)
        myVal := 4 ' change myVal to 4 but don't change to the next case "4" until other code has run below CASE
        NEXT ???     
      ' do some stuff including check external IC data, and other time consuming processes
    4:
      ' do some stuff

  ' start processing here if case is finished or "aborted".
  outa[myPin] := new_state
  process_change(myVal)  ' This MUST run before the CASE changes to the next number

Hal Albach

If memory serves, each instance of CASE ends with BREAK. For example;

switch (myVal) {
  case '1':
    <do stuff>
    break;
  case '2':
     <do other stuff>
     break;
.
.
.
  case '5':
    <do something else>
    break;
 default:
    <do this if no case match.
    break;
}

Each BREAK will skip to the end of the code block.

This is for C, I did not realize you were doing SPIN

eagletalontim

I took the first advice by using If variable < BadCondition ..... else MyVal := new value. I took all the time consuming stuff and put them in a cog so they would run all the time and update "global" variables that could be checked in the CASE. Thanks for the help!

ChrisGadd

Hal Albach wrote: »

If memory serves, each instance of CASE ends with BREAK. For example;

switch (myVal) {
  case '1':
    <do stuff>
    break;
  case '2':
     <do other stuff>
     break;
.
.
.
  case '5':
    <do something else>
    break;
 default:
    <do this if no case match.
    break;
}

Each BREAK will skip to the end of the code block.

This is for C, I did not realize you were doing SPIN

Works this way in SPIN also, with an implied break.

  n := 1
  case n
    1: FDS.str(string("1"))
    1,2: FDS.str(string("12"))
    1,2,3: FDS.str(string("123"))
    1,2,3,4: FDS.str(string("1234"))

Even though a 1 is a match for all four cases, only the first one gets executed.

EMHmark7

Facing same problem, my solution, not neet I know for some purists, is test the value with an if,
and put everything billow that needs to be aborted in the else.

The else block will execute if ok so far.