Chief Delphi - Editing Main.c

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

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

- - Editing Main.c (http://www.chiefdelphi.com/forums/showthread.php?t=24590)

Astronouth7303

31-01-2004 09:49

Editing Main.c

1 Attachment(s)

I have been thinking about this for a little while. Why not have 2 sets of initializations and loops? 1 for autonomous, 1 for regular. And while we're at it, include a HALT() routine. Here's my version. Where do I put the prototype for HALT()?

Dave Flowerday

31-01-2004 10:55

Re: Editing Main.c

Quote:

Originally Posted by Astronouth7303

It's an interesting idea, but I'd advise against it. I looked at what you did at main.c and there's two major problems that I see. The first is that your code now depends on the fact that autonomous will be active when the robot is powered on. I don't believe this will be the case at the competitions. I'm pretty sure that last year, when you were setting up your robot on the field, the "Disabled" bit was set but the "Autonomous" bit was clear. Then, when the round started, it would change from "Disabled - no auto" to "Enabled - auto mode" in one packet. Even if they did plan to have the autonomous bit set when you plug your robot in on the field, there might be a delay or something - I wouldn't rely on it.

The second problem is that once your autonomous routine ends, there's no going back. This probably isn't such a big deal, but if somehow one packet from the OI comes down during autonomous mode with the autonomous flag cleared, your robot will stop autonomous mode and you won't be able to get back in. I highly doubt this would happen since IFI checksums the packets to ensure that they are valid before passing them to the user cpu, but still.. you never know what might happen.

Finally, your idea of halting the robot is interesting, but I don't see the purpose for it. Why would you want your robot to ever shut down? And more importantly, why would you want code to do that in there when you compete? I know our drive team would be rather upset if we had code like that in our robot and then a bug or something caused that condition to occur... Also, if you really want to have this halt option, it would probably be a wise idea to turn off all your outputs beforehand (PWMs to 127, relay outputs off, etc).

deltacoder1020

31-01-2004 13:04

Re: Editing Main.c

there is also the fact that such could result in code duplication - you may use some of the same code for the Process_Data_from_Local as you would for autonomous.

KevinB

31-01-2004 18:49

Re: Editing Main.c

There really is no advantage to doing this. If you're worried about code readability, try splitting the actual code up into separate files like this:

Code:

if (autonomous_mode) {

#include "auton.c"

} else {

#include "manual.c"

}

mtrawls

31-01-2004 20:45

Re: Editing Main.c

Quote:

Originally Posted by KevinB

There really is no advantage to doing this. If you're worried about code readability, try splitting the actual code up into separate files like this:

Code:

if (autonomous_mode) {

#include "auton.c"

} else {

#include "manual.c"

}

Quote:

there is also the fact that such could result in code duplication - you may use some of the same code for the Process_Data_from_Local as you would for autonomous.

That's not such a big concern, though. If something increases readability, or efficiency, or some other desirable thing, you very may well say "re-usability be damned." Reducing code duplication is good because it reduces your work, and reduces the amount of errors creeping up because of subtly different versions ... but it isn't necessarily bad (not that it is--or isn't-- justified here). Oh, and all I really wanted was an excuse to say this (sorry that I forget who it was that said it): For code to be re-usable, it first has to be usable :)

Random Dude

31-01-2004 22:23

Re: Editing Main.c

Quote:

Originally Posted by mtrawls

What? #include statements are pre-processor directives ... they are (quite necessarily) executed before compilation and definately before you upload the code to the robot. For conditional includes, you'd have to use the pre-processor directive #ifdef ... #endif -- but this isn't what you mean to do. Presumably, everytime you run the robot you'd want to execute *both* autonomous mode, and manual mode -- meaning you'd more than likely want both "auton.c" and "manual.c" to be included every time. Instead of #include "auton.c", perhaps you mean some sort of function call, where the function is defined in auton.c? *color me confused*

That's not such a big concern, though. If something increases readability, or efficiency, or some other desirable thing, you very may well say "re-usability be damned." Reducing code duplication is good because it reduces your work, and reduces the amount of errors creeping up because of subtly different versions ... but it isn't necessarily bad (not that it is--or isn't-- justified here). Oh, and all I really wanted was an excuse to say this (sorry that I forget who it was that said it): For code to be re-usable, it first has to be usable :)

No, that *should* work as is.... since the preprocessor would stick both of the files in and then everything would compile. That being said, I do agree that making then relevant sections into functions (in seperate files if you insist), would make much more sense.

deltacoder1020

31-01-2004 23:08

Re: Editing Main.c

Quote:

Originally Posted by mtrawls

of course it does. i comment the heck out of my code, as well as try to arrange it in the most logical way possible :)

I think what Random Dude meant was that you could use #includes so that you could be sure that the code you were writing would be executed for one mode or another, depending on what file you put it in. that way, you still have both autonomous mode and operator mode, but the code for each is in separate files.

KevinB

31-01-2004 23:55

Re: Editing Main.c

Quote:

Originally Posted by mtrawls

I didn't use #ifdef or #endif because thats not what I'm trying to accomplsh. The #include directive simply takes the contents of that file and shoves it into the spot where the #include line was.

You get the conveinence of having the autonomous routine in 1 file and the main routine in the other file, and you save the CPU cycles necessary to jump to and from the function.

Larry Barello

01-02-2004 11:21

Re: Editing Main.c

It is perfectly reasonable to rewrite main(). I did it. I don't understand why IFI put in such a baroque superstructure in the FRC default code. The EDU code was cleaner.

You can replace *everything* that IFI gave you, except for their library. All I saved was the printf (modified slightly) and the main library with the rxget and txput routines since those are "hidden" in a library. The important thing to keep the same is how the IFI stuff is initialized and how you go about getting and putting the packet from the master CPU. Every thing else is fair game.

In short, my main looks like this:

Code:

void main (void)

{

#ifdef UNCHANGEABLE_DEFINITION_AREA

    IFI_Initialization ();        /* DO NOT CHANGE! */

#endif



    User_Initialization();        /* You edit this in user_routines.c */



    statusflag.NEW_SPI_DATA = 0;  /* DO NOT CHANGE! */



    while (1)

    {

#ifdef _SIMULATOR

        statusflag.NEW_SPI_DATA = 1;

#endif

        if (statusflag.NEW_SPI_DATA)    /* 26.2ms loop area */

        {

            Getdata(&rxdata);

            ProcessPacket();                        // User_routines.c

            Putdata(&txdata);           /* DO NOT DELETE, or you will get no PWM outputs! */

        }

        Process_Tasks();                // user_routines.c

    } /* while (1) */

}  /* END of Main */

and my user_code looks like this:

Code:



void ProcessPacket(void)

{

        int c;

        

        // Put common stuff here



        CheckSwitches();                        // Mass examine digital input for change



         if (autonomous_mode)

        {

                User_Autonomous_Code();

        }

        else

        {

                User_Normal_Code();

        }

        pwm01 = DoPid(&Left, &LeftEncoder);

        pwm02 = DoPid(&Right, &RightEncoder);

        

        //---------- Inputs to Relays--------------------------------------------



        relay8_fwd = !rc_dig_in18;  /* Power pump only if pressure switch is off. */

        relay8_rev = 0;

...

and finally, my "tasking code" which was more complicated, but now is pretty simple

Code:

void Process_Tasks(void)

{

        static char GyroTimer = 0, PrintTimer = 0;



        Poll_Rx1();                                        // The fast loop runs > 100khz

        Poll_Tx1();                                        // Poll rather than interrupts

        Poll_Rx2();

        Poll_Tx2();



    while (MsTimer)                                // Incremented by TimerInterrupt.

        {

                MsTimer--;                                // Section.



                if (++GyroTimer == 10)        // 100hz

                {

                        GyroTimer = 0;

                        Gyro_Task();

                } // END GyroTimer



                if (++PrintTimer == 100)        // 10hz

                {

                        PrintTimer = 0;

                        TetherTask(STDIO);

                } // END Print task

        }// END Tasking

}

In short my "packet driver" code does common stuff up front (read sensors) the calls appropriate normal or autonomous code, then at the back end formats up stuff to send out.

Just pay attention to those lines with /* DO NOT CHANGE */ appended to them. Not all, but most are important.

Also, if you are interested in my tasking code, I put a zip called "sensors.zip" out on one of the programming forums (PID or Gyro, one of the two...)

Astronouth7303

02-02-2004 14:19

Re: Editing 'forbiden' areas

Thanx, Every one!

Unfortunately, I didn't even compile the code I posted. I would be surprised if thier weren't syntax errors or whatnot.

Let's keep discussing about editing core areas for making code faster, more efficent, adding functionality, or just for the heck of it.

A few challenges:

write a template for a 'minimum-boot' program. just initialize, comment "//Put Stuff here!" and de-init
Write a full program from scratch. Doesn't have to do anything fancy, you just can't use anything from default code (except for lib declarations). :yikes:
Have you done it using ALL your own code (no libs)? let's hear about it!

Still cracking, Astronouth7303

djcapelis

05-02-2004 01:08

Re: Editing Main.c

If anyone really feels like abuse... would it be possible without messing with IFI stuff to actually write a full control with just ASM?

If so... anyone want to give it a try?

Astronouth7303

05-02-2004 17:50

Re: Editing Main.c

:yikes: Yikes, ouch, assembley language, yikes, ouch, wow. :SinksIn: You really took that to heart!

No, I don't know any asm's. But someone's got to do the first one. May be this will be an off-season thing.

Again, Yikes, ouch, wow.

Raven_Writer

05-02-2004 18:39

Re: Editing Main.c

Quote:

Originally Posted by djcapelis

If anyone really feels like abuse... would it be possible without messing with IFI stuff to actually write a full control with just ASM?

If so... anyone want to give it a try?

It is possible....after all MPLAB/C18 has ASM capabilities, and the processer converts the code into asm then binary (i believe) anyways.

Astronouth7303

07-02-2004 21:24

Re: Editing Main.c

I just remembered: some of IFI's routines are written in ASM (or ASM and C). Check those!

mtrawls

07-02-2004 21:36

Re: Editing Main.c

Hrm... editing main.c, sounds like a good idea. Only I can't. MPLAB won't let me change it -- it isn't accepting any input at all when I have that file in focus. Is there some sort of default protection to protect the unawares that I am unaware about? It was somewhat distressing when, during testing, I did actually want to put something there. Just another reason why MPLAB was getting me angry ... it has several, well "interesting" qualities.

Astronouth7303

07-02-2004 21:40

Re: Editing Main.c

Check that the file isn't read-only, and doesn't have other protection. If that doesn't work, there's always notepad.

PS to other Main.c readers: In the Programming code Fix FRC thread, a recent post brings up something about PWMs 13, 14, 15, and 16. READ IT!

Mark McLeod

08-02-2004 10:51

Re: Editing Main.c

Quote:

Originally Posted by mtrawls

In MPLAB with any file open go to EDIT -> Properties...
and unclick the "Protect Read Only files" box.

Raven_Writer

08-02-2004 11:28

Re: Editing Main.c

Why did IF protect almost all the source files anyways?

SeanCassidy

08-02-2004 18:00

Re: Editing Main.c

Quote:

Originally Posted by Raven_Writer

Why did IF protect almost all the source files anyways?

So your overzealous aspiring programming teammates don't destroy the source code I guess. ;)

Astronouth7303

08-02-2004 20:23

Re: Editing Main.c

Quote:

Originally Posted by SeanCassidy

So your overzealous aspiring programming teammates don't destroy the source code I guess. ;)

Oh, You have other programmers on your team? You got it good!

Joe Ross

08-02-2004 22:19

Re: Editing Main.c

Quote:

Originally Posted by SeanCassidy

So your overzealous aspiring programming teammates don't destroy the source code I guess. ;)

No, its to protect you from yourself.

Astronouth7303

09-02-2004 07:25

Re: Editing Main.c

Too bad, that's what this is about! :) Don't you feel safer now?

Astronouth7303

20-02-2004 16:45

Pause Function

copied from my other post.

Code:

#define PAUSE_SWITCH p4_trig //Change as necessary



//...

  while (1)   /* This loop will repeat indefinitely. */

  {

#ifdef _SIMULATOR

    statusflag.NEW_SPI_DATA = 1;

#endif

if (!PAUSE_SWITCH)

{

    if (statusflag.NEW_SPI_DATA)      /* 26.2ms loop area */

    {                                 /* I'm slow!  I only execute every 26.2ms because */

                                      /* that's how fast the Master uP gives me data. */

      Process_Data_From_Master_uP();  /* You edit this in user_routines.c */



      if (autonomous_mode)            /* DO NOT CHANGE! */

      {

        User_Autonomous_Code();        /* You edit this in user_routines_fast.c */

      }

    }

    Process_Data_From_Local_IO();     /* You edit this in user_routines_fast.c */

                                      /* I'm fast!  I execute during every loop.*/

}

  } /* while (1) */

//...

Basically, if you flip the switch, the robot will finish, and then go into a really fast loop: it does nothing until you turn it off. Be sure to put something similar in the auto.mode code: it has its own loop.

All times are GMT -5. The time now is 00:01.