Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   New C18 3.0+ Compatible FRC Code (http://www.chiefdelphi.com/forums/showthread.php?t=60377)

PhilBot 01-01-2008 11:26

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by Kevin Watson (Post 666036)
Here is a snapshot of the current build:

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

-Kevin

That's looking excellent.

trivial note: I don't know whether you update your comments along the way, or once the build has stabilized, but I just wanted to mention that the ifi_frc.c file still has all the old reference to user_code.c in it's comments.

Another thing I realized when I loaded this project was that your development environment and mine don't match, so it caused a hickup that may trip up first time users (me two years back:)

You have the CC18 environment loaded under the MPLAB program folder, wheras mine is loaded under the c:/ root. I have no idea if this was a decision of mine, or the compiler default (i think so), or a consequence of me simply "upgrading" last year's install, but it means that when I load your project, two things happen:

1) MPLabs prompts me as to whether I want to keep my old CC18 compiler and Linker folders or use the ones in the project (I say keep the old one)

2) I get a linker error because MPLAB can't find the clib library. I need to go to Build-Options/Directories/Library, and set the path from c:/program files/mplab/cc18/lib to c:/cc18/lib

My only reason for bringing this up is to determine what you, and the likely "critical mass" of users will be using. If CC18 should be loaded under MPLAB then I'll move mine. If this is contrary to the install default, then a "pre-install" readme would be a good idea to prevent (minimize) the initial confusion of new users.

Thanks for all the time you put in.

Phil.

ay2b 01-01-2008 14:45

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by Kevin Watson (Post 666097)
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?

I believe it should be called every time that the robot enters into disabled mode.

Guy Davidson 02-01-2008 18:42

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by lukevanoort (Post 665163)
You could basically copy and paste the code from the encoder driver's ISRs into the ISRs in this version (or put them in another file and call them from the ISRs, which would probably be more readable) and add the Get_Encoder_x_Count() function. Actually, if you just didn't call the initialization functions, you could probably use the current encoder code verbatim (well, for encoders one and two anyway, for 3-6 you'd probably just want to reuse the code from encoder 1-2 instead of the encoder driver's functions for encoders 3-6). I would say that it would probably be less than 20mins to code.

Thanks. For now, I commented out the code for encoders 3-6, and I use the code for 1 and 2 by having the Int_1_Handler() in interrupts.c call on Encoder_1_Int_Handler() in encoder.c. This sounds like it should work, and I'll post here if it works or if it fails and I can't figure it out by myself.

How about gyros? I noticed that your gyro code from last year uses both gyro.c/h and adc.c/h. I copied both of thme, and I've been fumbling for a while with integrating them and timers.c. I have not been able to do that yet, generating a red-light-of-doom in the process. Any ideas or advice?

EDIT: Kevin, I believe I may have found a problem. Interrupts.h uses #define ENABLE_INT_# (for # being 1,2,...), while ifi_frc.c checks #ifdef ENABLE_INTR_# when checking for the ISR. That is an oversight, right? I searched the rest of the files and could not find another reference to ENABLE_INTR_#.

billbo911 02-01-2008 20:23

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by Kevin Watson (Post 666097)
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

Another thought popped into my head about Disabled_Init(). The three times a robot gets disabled is true in most years games, but some years it happens a lot more. Remember 2005, every time the human player stepped off the enable mat to load a Tetra on a robot, that robot was disabled. So, with this in mind, the function would definitely need a flag that would only allow it to initialize on reboot or power up.

Kevin Watson 02-01-2008 21:23

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by sumadin (Post 666720)
Thanks. For now, I commented out the code for encoders 3-6, and I use the code for 1 and 2 by having the Int_1_Handler() in interrupts.c call on Encoder_1_Int_Handler() in encoder.c. This sounds like it should work, and I'll post here if it works or if it fails and I can't figure it out by myself.

How about gyros? I noticed that your gyro code from last year uses both gyro.c/h and adc.c/h. I copied both of thme, and I've been fumbling for a while with integrating them and timers.c. I have not been able to do that yet, generating a red-light-of-doom in the process. Any ideas or advice?

EDIT: Kevin, I believe I may have found a problem. Interrupts.h uses #define ENABLE_INT_# (for # being 1,2,...), while ifi_frc.c checks #ifdef ENABLE_INTR_# when checking for the ISR. That is an oversight, right? I searched the rest of the files and could not find another reference to ENABLE_INTR_#.

You might want to wait on the encoders as I have a scheme to make the encoder ISRs more efficient. I'll be coding it up sometime in the next few days.

I'll also port the ADC code too at some point (I need to find a better way of installing ISRs).

I'll look into the INTR vs. INT issue this evening. It's probably just some knuckle-headedness on my part. Thanks for catching it.

-Kevin

Mike Mahar 03-01-2008 15:03

Re: New C18 3.0+ Compatible FRC Code
 
How do you get a version 8 MPLAB? The disks that we've received from FIRST were all version 7.20. IFIRobotics' web site still claims that they only work with 7.20. I didn't notice the MPLAB requirement and now I have a hybred system that won't compile my 2.4 code nore will it open Kevin's new workspace.

Tom Bottiglieri 03-01-2008 15:14

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by Mike Mahar (Post 667105)
How do you get a version 8 MPLAB? The disks that we've received from FIRST were all version 7.20. IFIRobotics' web site still claims that they only work with 7.20. I didn't notice the MPLAB requirement and now I have a hybred system that won't compile my 2.4 code nore will it open Kevin's new workspace.

www.microchip.com
It's free

EHaskins 03-01-2008 15:15

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by Mike Mahar (Post 667105)
How do you get a version 8 MPLAB? The disks that we've received from FIRST were all version 7.20. IFIRobotics' web site still claims that they only work with 7.20. I didn't notice the MPLAB requirement and now I have a hybred system that won't compile my 2.4 code nore will it open Kevin's new workspace.

MPLab v8 can be downloaded directly from Microchip.com.

I have had no issues running c18 v2.4 or v3.10 with MPLab v8.

Your 2.4 code will not compile with c18 v3, and the MPLab v8 workspaces will not open in older versions of MPLab. If you want to be able to compile your 2.4 code, you'll need to copy the mcc18 folder from a computer with 2.4 installed, and change the header, linker, and library serch folders of you 2.4 projects to point to the 2.4 folders.

Code Monkey 03-01-2008 15:34

Re: New C18 3.0+ Compatible FRC Code
 
Last year we got an updated adc code which only used 1 interrupt per sample, instead of 2. Is this already implemented in the new adc code? Also last year we had to use a new processor .h file for the encoders. I see the encoder work is in progress, so this will also disappear, I hope?

Isn't it new to be able to program for the disabled mode? Is there a hint there?

EHaskins 03-01-2008 15:41

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by Code Monkey (Post 667114)
Isn't it new to be able to program for the disabled mode? Is there a hint there?

Previously the same code would be run in the robot was Disabled or Enabled. The outputs were just disabled.

lukevanoort 03-01-2008 16:02

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by EHaskins (Post 667118)
Previously the same code would be run in the robot was Disabled or Enabled. The outputs were just disabled.

Actually, you could always determine if the robot was disabled or enabled, the default IFI code just didn't make use of it and neither did most teams' custom code.

My team, and probably several others (I know Chief Delphi does it or at least did it at one point), implemented mode determination to help prevent integrator wind up in PID loops.

EHaskins 03-01-2008 16:04

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by lukevanoort (Post 667125)
Actually, you could always determine if the robot was disabled or enabled, the default IFI code just didn't make use of it and neither did most teams' custom code.

My team, and probably several others (I know Chief Delphi does it or at least did it at one point), implemented mode determination to help prevent integrator wind up in PID loops.

That's the only reason I ever did it.

Code Monkey 03-01-2008 16:25

Re: New C18 3.0+ Compatible FRC Code
 
Looking back at other posts, I see that now. It is nice for newer teams to see that they could initialize the gyro while siting and waiting for the match to begin. Now that is explicit. This newer code does look straight forward.

I won't get a chance to actually download this into a CD prior to kick off, but will spend my lunches studying it.

Thanks to all of you already solving problems!

Capt. Quirk 03-01-2008 18:08

Re: New C18 3.0+ Compatible FRC Code
 
I see there is a .lkr file 18f8520, does that mean I can play with it on a VEX bot?

EHaskins 03-01-2008 18:09

Re: New C18 3.0+ Compatible FRC Code
 
Quote:

Originally Posted by Capt. Quirk (Post 667223)
I see there is a .lkr file 18f8520, does that mean I can play with it on a VEX bot?

No, you also need a version of the library for vex.


All times are GMT -5. The time now is 22:34.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi