Re: New C18 3.0+ Compatible FRC Code
 

Looks like another bug in their header file. Your options are to replace the 2.4 p18f8722.h with the 2.44 version in the Documentation folder included with my code, or you can update your compiler to 2.44, which is the same version I use. Here's the link to the secret copy I keep on my website: http://kevin.org/frc/c18_244_update.zip.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

How many folks out there are using this code with MPLAB IDE v7.20 and MPLAB C18 2.4? I noticed a comment in encoder.h as follows:

This version is compatible with Microchip C18 3.0+ only

Is this still true?

Re: New C18 3.0+ Compatible FRC Code
 

Ugh. Um, I guess I was a knucklehead and forgot to delete that comment. The code works file with 2.4.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

That's what I had guessed, thanks for clarification. Note that this comment also appears in at least one other file as well (interrupts.h), possibly others, too.

Re: New C18 3.0+ Compatible FRC Code
 

Another ADC and Gyro question :)

We want to use the gyro as well as other analog sensors. It appears that using Process_Gyro_Data() in Teleop_Spin(), for example, will check for ADC result count, read the ADC gyro channel only and then reset the ADC result count without reading any other ADC channels. Is that a problem?

The 2007 Process_Gyro_Data() didn't check for ADC result count or do a reset inside the function, so we read our other channels just after Process_Gyro_Data() and before the reset.

Where should ADC channels for our other sensors be read? Do they need to be read in the fast loop at the same time as the gyro channel is read? (Should we insert more Get_Analog_Result()s in Process_Gyro_Data to read the other channels?)

We're using pots with a PID to control steering etc., and ultrasonic sensors.

Thanks...

Re: New C18 3.0+ Compatible FRC Code
 

Yes it is. I would modify Process_Gyro_Data() to not reset the the ADC result count, but make sure it does get reset after processing all your other sensor data. I think I'll modify Process_Gyro_Data() to accept a TRUE/FALSE parameter to determine how it behaves in this regard. Thanks for catching another knuckleheaded mistake on my part <grin>.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

We've already done this, but why the recommendation to "reset after processing...other...data"? We simply remember the last count and make sure it has changed before processing more data. That way we are sure to be processing fresh stuff and don't need to tie it all together to get a reset when everyone has had their chance at the latest readings....

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

And I've been remiss in sending "Thanks" to Kevin, but our software group is LOVING the new code format. It is much more understandable than the earlier default code.

One change we've made is to add a few "always" functions. We hooked them in to the main program and they're called "Always_Spin", "Always_Before", and "Always_After". They get called regardless of the current operating mode. The *_Before and *_After routine get called before and after the invocations of the mode's command packet processing routine.

We did this after we found ourselves adding the same invocations to Disabled_Spin, Teleop_Spin, and Autonomous_Spin for the third time. Always_Spin makes it easy.

Always_After is a handy place to get a last chance to reverse any PWM values for opposing drive motors without having to remember to do it everywhere else. Positive logic rules with the ability to override it for reality where necessary. (Robots shouldn't go forwards when you set PWMs to 0, but when mechanical mounts opposing motors and controls wants red to red to positive consistency, it falls to software to make it all work right).

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

Yes, this works too, but keep in mind that the value returned by ADC_Result_Count will roll over at some point, so make sure to use the != operator instead of > in your test (I know you know this Lynn; I'm just mentioning this so others won't make a mistake).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I'm having trouble with the Gyro bias calculation in the code posted on 2/2. If I use the previous code (without the circular buffer), I get a gyro bias of ~2080. With the newer code, I get a gyro bias of ~1660. This make the code think the gyro is spinning continuously. Is there an OBO (off by one) error lurking somewhere? Is anyone else having problems with the updated code?

Re: New C18 3.0+ Compatible FRC Code
 

btw
I had a problem, I was trying to declare a variable in "interrupts.c",
and use it also in "autonomous.c,"
no matter what i've tried, it didn't work
(nope, trying to redeclare it as an extern in the header didn't work either),

strangely enough, after wasting an hour like an idiot :D,
I've declared it in autonomous.c and it worked like a charm.

incredibly weird..

Re: New C18 3.0+ Compatible FRC Code
 

Kevin

What is the difference in master code from the 2007 controller and the 2008 controller... is there a procedure to update a 2007 controller to the current master code?? I understand that the hardware is 100% the same...

thanks...

Re: New C18 3.0+ Compatible FRC Code
 

There is no difference in the hardware or firmware between the 2007 and 2008 robot controllers. The latest revision of the master firmware is version 15, available here:

http://www.ifirobotics.com/docs/frc-master-ver15.zip

You use the IFI loader to send it to the robot controller (the boot loader intercepts it and sends it to the master).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

We just uncovered (and fixed) a potential gotcha in the invocation of Teleop_Init() from main. We tried to access the current state of the OI inputs from there and they weren't available!

We found that the Getdata() call was occurring AFTER the Teleop_Init(). We moved it BEFORE the if(teleop_init_flag) test and it corrected our problem.

On further inspection as I'm writing this, the same issue would plague the other two *_Init() invocations. Simply moving the Getdata call will make the current OI data available to those functions.

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

Hmmm... I'll have a look at it later tonight.

Edit: I'll change it when I make the changes mentioned above, but I don't see where this could cause a ploblem as the OI data from the previous Getdata() should be valid. What problem were you having?

-Kevin

-Kevin