Re: New C18 3.0+ Compatible FRC Code
 

We(1103) willl be using this code. So far it looks good.

Re: New C18 3.0+ Compatible FRC Code
 

Well in ver 3.10 of the compiler the .map file will NOT show an entry if there is no storage needed, but 3.15 will show a null entry. (as it should)

Re: New C18 3.0+ Compatible FRC Code
 

Hi Kevin.

Your new structure makes a lot more sense. I never liked the way the old code fell into the "autonomous" pit and never came out.

I installed MPLAB8 and upgraded to cc18 3.1. Other than the typical include/lib path issues asociated with any upgrade, your new code built just fine.

My own personal preference is to use more, smaller files, so my vote would be to split the auto and disabled modes out into sepparate files. I beleive that this would actually make it easier for teams not addressing these modes because they wouldn't have to keep scrolling arround the empty functions.

If you are lucky to have more than one programmer on the team, it does enable the "Autonomous" mode programmer to work somewhat independantly of the "teleop" programmer. Last year I also had c&h files for each of the four subsystems: UserIF, Drive, Manipulator and Vision, and assigned each subsystem to a student. It kept them out of each other's hair, and made it easier to see what had changed from version to version. Not much downside to extra files.

To Fill up the new files a bit, I would also vote for including the init_ functions. So, each of the mode files would have an init, spin and run function.

I also agree with the recomendation for teams to have a robot.h and robot.c file. It's the first thing I add to the standard ifi code. In my case this is where I put all my #defines for translating the cryptic I/O port names to robot functions, and code for enforcing various robot safety limits.

Team 1629 will definately be using your new code so I'm eager to see you fold all your other cool functions into this structure.

Phil.
A happy camper:D

Re: New C18 3.0+ Compatible FRC Code
 

Wow Kevin! I love it already. Everything is so well organized and everything is incorporated. This will be a really good tool for rookies as well as veteran teams :). I will definitely be using this on our 2008 robot :D

Re: New C18 3.0+ Compatible FRC Code
 

Just noticed this:

In your pwm_readme.txt file, you still reference Process_Data_From_Master_uP()

I guess this would now be: Teleop() and Autonomous(), although I see you make the call after these functions.

Phil.

Re: New C18 3.0+ Compatible FRC Code
 

Okay, I've implemented most of this. Is there really a need for a Disabled_Init( ) function?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Good question!

One way to look at it is:
During Competition, the systems boot up in Disabled mode. It wouldn't be a bad place to do some of the system initializations, Pre-calibrations and OI input gathering. Gyros would love the fact that the bot is not moving and compressors aren't running.

On the other hand, it is a bit redundant considering the Initialize () routine already exists in user_code.c.

Honestly, I say, give it the boot. (Yes, pun intended:ahh: )

Re: New C18 3.0+ Compatible FRC Code
 

Here is a snapshot of the current build:

http://kevin.org/frc/ifi_frc_beta_2.zip

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I would say it isn't. To my understanding (and the way I'd use it) the whole point of the disabled function is to initialize variables and do some setup. Hence, as far as I'm concerned, there's no need for an initializing function to the initializing function.

Re: New C18 3.0+ Compatible FRC Code
 

Checking our code for the last few years, we've had a Disabled_Init(), but mostly just used it for debugging. I think it's worth including, just for completeness. Similarly, each year we've had a Disabled_Spin() function[*], but it's always been empty. I think it's worth having all three functions (run, spin, init) in the framework for each mode.

[*] actually we called ours Disabled_Fast_Loop(); and the run function was Disabled_Slow_Loop(), but I think I like _Spin() and _Run() better.

Re: New C18 3.0+ Compatible FRC Code
 

Well as I understand it, you're still getting valid data from the OI in Disabled mode and teams have used this fact to select auto modes before matches start. So presumably, you'd want a Disabled_Init() to re-initialize this variable to a default value if you had to do a restart. I can see uses for it, but mostly I think it should be left in just for consistency between the different modes.

Re: New C18 3.0+ Compatible FRC Code
 

Okay, it's easy enough to do, but disabled mode is nominally called three times each round (before autonomous, between autonomous and teleop, and after teleop). Should Disabled_Init( ) be called each time, or only the first time? If only the first time, under what conditions would the default_init_flag get reset?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

It should be called only the first time and then reset on power cycle or on RC reset.
Just my opinion.

Re: New C18 3.0+ Compatible FRC Code
 

I would agree, but I am a person who likes to keep options open. With that goal in mind, I think it would be ideal to put the code that calls Disabled_Init() in an #ifdef conditional so a programmer can just quickly define/undefine something to change the behavior.

Re: New C18 3.0+ Compatible FRC Code
 

In answer to your initial question about the need for a Disabled_Init() function... we also used this to trigger calibrating the Gyro. The actual callibration only occured if we stayed in disabled mode for several seconds.

We put in the delay because we didn't know if the system transitioned through Disabled between auto and teleop. Based on your post, I'm glad we took that precaution.

We also did it for code symetry more than anything else.... Yes, I also indent all my "=" signs the same amount. Just call me anal.

I think the Disabled_Init() is most usefull once before the match begins, so that would mean that you wouldn't really want it called between Auto and teleop.

I thought that it might also be good to call it on the transition from Teleop back into Disabled (to indicate that there might have been a field reset situation after a bad start) but the bot is in an unknown state at that time anyway (maybe on it's side) so you wouldn't necessarily want to make any callibration assumptions.

In the end I guess this function would only be called after reset, so it is a bit redundant with Initialize(). Although, if the function is resetting variables that only get used in disabled mode, then my anal side says that that's where they should be declared and initialized :) This is also what we did with our UserIF, Drive, Manipulator and VisionSystem variables. Declared and initialized in subsystem modules.

Thanks for even considering it :rolleyes:
Phil.