Chief Delphi - user_routines

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - user_routines_fast (http://www.chiefdelphi.com/forums/showthread.php?t=60146)

user_routines_fast

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.

Re: user_routines_fast

The user_autonomous_code function is indeed fast:

Code:

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):

Code:

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.

Re: user_routines_fast

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!

Re: user_routines_fast

Quote:

Originally Posted by neutrino15 (Post 659641)

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

Re: user_routines_fast

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!

Re: user_routines_fast

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.