user_routines_fast

[neutrino15]

I was just wondering, why the autonomous loop is in user_routines_fast if it waits for new rxdata anyway? Doesn't this make it execute just as slow as the regular user_routines file? Also, exactly how fast is user_routines_fast?

Note: I am working with kevin watson's code.

[Bongle]

The user_autonomous_code function is indeed fast:

void User_Autonomous_Code(void)
{
  // ... stuff deleted for clarity
  while (autonomous_mode)   /* DO NOT CHANGE! */
  {
    // this part here happens over and over very very quickly
    if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
    {		
        // ... stuff deleted for clarity
        // this code is only executed once every 26.2ms
    }
    // back to really really fast code here
  }
}

When you're waiting the RC to indicate that there is new data, you're just doing a busy loop spinning around the while(autonomous_mode) loop. This will happen as fast as the RC can do it, which is entirely dependant on how much code is there.

If you wanted to know how fast that is without any code to execute, you could do this (note that lots of default code here is omitted for clarity):

void User_Autonomous_Code(void)
{
  int cExecutions;
  
  while (autonomous_mode)   /* DO NOT CHANGE! */
  {    
    if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */
    {  
        // I don't remember the exact printf syntax, it has been awhile
        printf("%d\r\n cycles in 26.2ms means %d per second",cExecutions,(10000*cExecutions)/262)); 
        cExecutions = 0;
    }
    cExecutions++;
    // back to really really fast code here
  }
}

So cExecutions will increment on every fast loop, then once you get into the 26.2ms code, you print it out and reset it to zero. This way, you can tell how many fast loops occurred per slow loop, and thus derive how many fast loops you get per second. But keep in mind, the fast loops per second count will change dramatically as you add new code to the fast-loop portion.

[neutrino15]

Ahh, I understand.. So it would be completely necessary to use interrupt hardware timers here then! Also, what is the point of putting auton code in a fast loop? I mean, if you only get data every 26ms, what would you do in between that? (besides run some really smooth PID, i guess)
Thanks for clarifying that though!

[Alan Anderson]

Originally Posted by neutrino15

...what is the point of putting auton code in a fast loop? I mean, if you only get data every 26ms,...

While in autonomous mode, the "data" you get is irrelevant. It is forced by the system to indicate all joysticks at neutral, and all switches open.

The point is so you can do whatever you want, however quickly you want, without being restricted to a 38 Hz cadence.

[neutrino15]

Oh, wait.. which function processes the local data?
Process_Data_From_Local_OI()
would make sense.. Ok, so you HAVE sensor data during the fast loop, just not input from the operator interface. That makes more sense!

Thanks!

[Kevin Sevcik]

Erm. To the point in the original question: autonomous mode is in User_Routines_Fast mostly just because that's how IFI has structured it. You could put it elsewhere and it would work just fine. But since any fast loop functions you might be calling would probably be defined in User_Routines_Fast, and since you'd probably need those in the fast part of your autonomous loop, it's easiest to put it there.

The basic flow of execution means that whenever the autonomous mode bit is set, you get kicked out of the tele-op loop and shunted into a very very similar autonomous mode loop. Really, you should think of the autonomous code as being exactly the same as your normal code, except you're not getting any valid input from the OI. But note that this does NOT mean that you don't need to wait for new rxdata. rxdata and txdata come from the master processor. Yes, the rxdata has the joystick data from the OI bundled up in it, but it has some other stuff from the master processor besides. Like the disable/enable bit and the autonomous/tele-op bit. More importantly, you HAVE to send the txdata back to the master processor shortly after it sends you an rxdata, or else the watchdog timer will time out and you'll get the dreaded red code light of death. Plus, txdata contains the PWM output values for the 12 PWMs that the user processor doesn't control, so not sending it would mean those 12 PWMs wouldn't do anything.

So, in summary, the autonomous loop is where it is for convenience, and waiting for rxdata is vital in ANY loop you might be in on an IFI controller.