Switch between two codes

So I have a robot. I have two codes: One for autonomous mode (obstacle avoiding robot with servo and ultrasonic sensor) and manua using bluetooth (HC-05). I want to switch between these two codes when needed with like, a switch or something. Can you give me a code pls?

Is it a big sketch? Then I don’t want to see it but perhaps you can tell why autonomous mode prevents you from interrupting it?

Does your code use delay() or wait-loops?

Yes, both codes have delay, especially the autonomous mode

By "two codes" presumably you mean two sketches?

I'd try something along the lines of combining the sketches into one, which would probably mean having the contents of the 2x existing loop() functions stuck into their own functions say auto() and btooth() or whatever.

Then read a switch in loop() and invoke either of the functions as required. You would need to make sure your existing code, in the 2x new functions, doesn't block, so that the switch is read in loop() often enough to make your movement between the modes more or less seamless.

Then both codes have times when a button can't be seen. You have hit a limit of delay code.

Would you like to learn how to fix that, keeping most of all of your code except the delays? The modes will run exactly the same but you gain the ability to make other things work at the same time, like a mode switch.

This works. Consider that delay(1) loses 16000 cpu cycles and a small sketch might run 300 cycles per loop(). The delay blocks the sketch from running more than 50 times in a row just for 1 ms. More normal is 10 to 1000. The code to react to the button pin would be part of that not-running sketch.

There is a clear, well made tutorial about exactly this problem by forum member Nick Gammon. http://gammon.com.au/blink

He includes code and this explanation:

But what if you want to blink the two LEDs at different rates? Like, once a second for LED 1 and twice a second for LED 2?

This is where the delay function doesn't really help.

Let's look at an analogy. Say you want to cook breakfast. You need to cook:

Coffee - takes 1 minute Bacon - takes 2 minutes Eggs - takes 3 minutes

Now a seasoned cook would NOT do this:

Put coffee on. Stare at watch until 1 minute has elapsed. Pour coffee. Cook bacon. Stare at watch until 2 minutes have elapsed. Serve bacon. Fry eggs. Stare at watch until 3 minutes have elapsed. Serve eggs.

The flaw in this is that whichever way you do it, something is going to be cooked too early (and get cold).

In computer terminology this is blocking. That is, you don't do anything else until the one task at hand is over.

What you are likely to do is this:

Start frying eggs. Look at watch and note the time. Glance at watch from time to time. When one minute is up then ... Start cooking bacon. Look at watch and note the time. Glance at watch from time to time. When another minute is up then ... Put coffee on. Look at watch and note the time. When 3 minutes are up, everything is cooked. Serve it all up.

In computer terminology this is non-blocking. That is, keep doing other things while you wait for time to be up.

But please note that when your code is non-blocking, it can react to random events. You get RTS vs turn-based code. Is that worth a little read-and-do? And we turbo your sketch to work the same but add a mode switch?

juma_yetu: By "two codes" presumably you mean two sketches?

I'd try something along the lines of combining the sketches into one, which would probably mean having the contents of the 2x existing loop() functions stuck into their own functions say auto() and btooth() or whatever.

Then read a switch in loop() and invoke either of the functions as required. You would need to make sure your existing code, in the 2x new functions, doesn't block, so that the switch is read in loop() often enough to make your movement between the modes more or less seamless.

My guess is that 2 sketches were combined but can only be run as one or the other. Both modes block even themselves.

GoForSmoke: My guess is ...

Hehe yeah and that's the problem: OP didn't really explain.

But did verify the delays.

Maybe the OP is working through the tutorial in between real life weekend.

When there is code that does some things, waits, and repeats that few or many times, the whole sequence can be cut into what is done and the waits between as a step by step process.

I put all that code into a void function() that will run over and over in loop, it may need to check the time against a wait.

I only need one timer for all the delays being replaced, each sets start time and how long to wait then the one timer runs it.
So you will see a 1-shot timer at the start of the function, it only runs when set and turns itself off when done.

After the timer is a switch-case statement. A variable holds which step to run, at the end of the step the variable is ++.

In code it looks like this, only with more code in the steps.

not tested

void undelayExample() // this function does not block yet does run code steps on time
{
  static byte doStep =0; // static variables stay when scope ends, hold values
  static unsigned long doWaitStartMs; doWaitMs = 0;

  if ( doWaitMs > 0 )  //  1-shot timer only runs when wait > 0
  {
    if ( millis() - doWaitStartMs < doWaitMs )  // wait is NOT over
    {
      return;  //  instead of waiting in a delay(), the rest of the sketch gets a chance to run
    }
    else  //  wait is over
    {
      doWaitMs = 0;  //  turn 1-shot off
    }
  }

  switch ( doStep )
  {
    case 0 :  //  doStep == 0
    // do the first step
    doStep = 1;  //  when the timer finishes, the next step code will run
    doWaitStartMs = millis();  //  set start time for the timer
    doWaitMs = 100;  //  setting wait time triggers the 1-shot timer next time the function is run
    break;

    case 1 :  //  doStep == 1
    // do the second step
    doStep = 2;  //  when the timer finishes, the next step code will run
    doWaitStartMs = millis();  //  set start time for the timer
    doWaitMs = 500;  //  setting wait time triggers the 1-shot timer next time the function is run
    break;

  ............................................

    case 20 :  //  doStep == 20
    // do the last step
    doStep = 0;  //  when the timer finishes, the next step will be the start
    doWaitStartMs = millis();  //  set start time for the timer
    doWaitMs = 60UL*60UL*1000UL;  //  run again an hour from now, UL is to keep the compiler from using 16-bit signed
    break;
  }
}