changing main.c

[3dude_2231]

Hi,
am I allowed to change main.c
so that when autonomous mode is on,
Process_Data_From_Master_uP won't execute?

I have things in my default_routine that shouldn't work during autonomous,
and I'm not sure whether the DISABLE function will disable them or not.

thanks,
Ran.

[Shinigami2057]

If you are in autonomous mode, Process_Data_From_Master_uP will never be called. User_Autonomous_Code() has its own fast/slow loops separate from Process_Data_xxx. If you don't want it to be called BEFORE it goes into autonomous code, you can move it after the if(autonomous_mode) check, or check for it at the beginning of Process_Data_xxx and return otherwise.

[EHaskins]

Originally Posted by Shinigami2057

If you are in autonomous mode, Process_Data_From_Master_uP will never be called. User_Autonomous_Code() has its own fast/slow loops separate from Process_Data_xxx. If you don't want it to be called BEFORE it goes into autonomous code, you can move it after the if(autonomous_mode) check, or check for it at the beginning of Process_Data_xxx and return otherwise.

Process_Data_From_Master_uP will be called while your robot is sitting disabled before a match. If you don't want to have it run before operator control you will need to setup a global variable that gets set to 1 once autonomous starts, and check the state of that variable before you run any code that can't run.

[Astronouth7303]

Originally Posted by 3dude_2231

Hi,
am I allowed to change main.c
so that when autonomous mode is on,
Process_Data_From_Master_uP won't execute?

IMHO, if they don't want us to change it, they wouldn't give us the source. All the exciting stuff is on the master processor anyway.

[Hieb]

I'm not sure if you can change it. It's been a couple of years since I've even tried, but several of the files (those that say "Do Not Change" or something like that) used to be locked so you couldn't change them.

[tdlrali]

Go ahead and change them. There is nothing wrong/illegal about that.
Just make sure you know what you are doing!

I'm not sure if you can change it. It's been a couple of years since I've even tried, but several of the files (those that say "Do Not Change" or something like that) used to be locked so you couldn't change them

Who cares what the comments say
And if they are locked, just take out the write protection (right click in explorer)

[3dude_2231]

OK, but is it right to add
if(!autonomous_mode) just before Process_Data_From_Master_uP()?

[tdlrali]

If you do not want Process_Data_From_Master_uP() running while in auton, then, yes, the following would do it.

if (!autonomous_mode)

      {

        Process_Data_From_Master_uP();

      }

[3dude_2231]

thanks,
BTW, you don't have to add the "{","}"s when you have only one function.

[half geek]

Correct me if I am wrong, but I think Process_Data_From_Master_uP() will never be called while in autonomous code since User_Autonomous_Code() has its own while loop:

void User_Autonomous_Code(void)
{
/**autonomous initialization....*/
  while (autonomous_mode)
  {
    /**autonomous routine..*/
  }
}

[Alan Anderson]

Originally Posted by half geek

Correct me if I am wrong, but I think Process_Data_From_Master_uP() will never be called while in autonomous code...

Consider yourself corrected. Take a look at the main() function in main.c and you'll see that it calls Process_Data_From_Master_uP() just before checking autonomous_mode. So it calls the "slow loop" code continuously before going autonomous, and then calls it one more time after autonomous is enabled and before calling User_Autonomous_Code().

Rather than modifying main() as 3dude_2231 is asking, it might be less traumatic to check for autonomous_mode inside Process_Data_From_Master_uP().

[jdejoannis]

Originally Posted by 3dude_2231

I have things in my default_routine that shouldn't work during autonomous,
and I'm not sure whether the DISABLE function will disable them or not.

What "things"? Once the autonomous loop is entered, the ordinary "things" (e.g. joystick inputs) in Process_Data_From_Master_uP will be overwritten.

Jason

[half geek]

Originally Posted by Alan Anderson

Consider yourself corrected. ... it calls the "slow loop" code continuously before going autonomous, and then calls it one more time after autonomous is enabled and before calling User_Autonomous_Code().

Thanks, I didn't notice that.

Originally Posted by Alan Anderson

Rather than modifying main() as 3dude_2231 is asking, it might be less traumatic to check for autonomous_mode inside Process_Data_From_Master_uP().

That makes sense as an option; but I am not sure why it would be a problem to add an if(!autonomous_mode) in main(). With what might this cause trouble?

[Astronouth7303]

There is nothing illegal or wrong with modifying any of the code to suit your needs. The only requirement is that you call IFI's functions as appropriate. You may modify main.c, ifi_utils.c, ifi_startup.c , or any other source file.

Now, your skill level is more likely a hinderence. I would imagine that 99% of the people here wouldn't dare touch ifi_startup.c. (The other 1% is Kevin Watson. ) Why? It involves initializing clib, clearing memory, and a few other low-level things. Half of it is written in inline assembly. I've only perused it a few times, nevermind modifying it.

As for the original question: modify main.c until you turn blue! Just be ready to post a lot of code when it doesn't work.

[Kevin Sevcik]

On the other hand, you can learn a lot by looking through all the files. For instance, ifi_aliases.h tells me that there's a flag called disabled_mode that will tell you if the robot is disabled. Much much easier and safer than setting some random variable after you've been in autonomous mode.

Second, I have a strong suspicion that Process_Data_From_Master_uP MUST be called atleast once. I'm pretty sure the GetData(&rxdata) call is what updates ALL of the information on the processor. Including whether or not you are in autonomous mode. If you don't call it while you're disabled and waiting for autonomous mode, you'll never enter autonomous mode. I believe you can get around these restrictions, but you're going to have to be a lot more clever than anything I've seen in this thread so far. Something on the order of swapping the order of the two calls as suggested above AND setting autonomous_mode=1 in your user initialization and also making sure you stay there while you're waiting for the initial disabled period to end and the actual autonomous mode to begin. Probably plus some other clever things I'm not thinking of at midnight. The point being, if you want to play with these files, you can. But you'll have a lot more fun at it if you actually know what's going on.