|
#61
|
||||
|
||||
|
Re: New C18 3.0+ Compatible FRC Code
We(1103) willl be using this code. So far it looks good.
|
|
#62
|
|||
|
|||
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
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) |
|
#63
|
|||||
|
|||||
|
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 ![]() Last edited by PhilBot : 31-12-2007 at 18:20. |
|
#64
|
||||
|
||||
|
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 ![]() |
|
#65
|
|||||
|
|||||
|
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. |
|
#66
|
||||
|
||||
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
-Kevin |
|
#67
|
||||
|
||||
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
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 ) |
|
#68
|
||||
|
||||
|
Re: New C18 3.0+ Compatible FRC Code
|
|
#69
|
|||
|
|||
|
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.
|
|
#70
|
||||
|
||||
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
[*] actually we called ours Disabled_Fast_Loop(); and the run function was Disabled_Slow_Loop(), but I think I like _Spin() and _Run() better. |
|
#71
|
|||||
|
|||||
|
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.
|
|
#72
|
||||
|
||||
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
-Kevin |
|
#73
|
||||
|
||||
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
Just my opinion. |
|
#74
|
||||
|
||||
|
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.
|
|
#75
|
|||||
|
|||||
|
Re: New C18 3.0+ Compatible FRC Code
Quote:
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 Phil. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Does the camera code suits to all versions of MPLAB and C18? | razer | Programming | 3 | 04-01-2007 14:50 |
| Trying to follow C18 interrupt context code... | dcbrown | Programming | 5 | 21-12-2006 09:01 |
| Error w/ FRC code | JamesBrown | Programming | 2 | 08-01-2005 16:17 |
| Programming code Fix FRC | Ferazel2001 | Programming | 6 | 08-02-2004 02:46 |
| FRC default code | hedgehogger | Programming | 2 | 21-01-2004 18:41 |