New C18 3.0+ Compatible FRC Code

[Kevin Watson]

Originally Posted by paulcd2000

It has been explained how to add encoders to the gyro code, how about the reverse?

Assuming you want to add the gyro code to your project, lets see if I can do this off the top of my head:

1) Add adc.c/.h and gyro.c/.h to your project directory.
2) Add adc.c/.h and gyro.c/.h to your MPLAB project.
3) Add #include "adc.h" and #include "gyro.h" at the top of teleop.c.
4) Add a call to Initialize_ADC() and Initialize_Gyro() in teleop.c/Initialization().
5) If needed, add #include gyro.h to the top of autonomous.c and/or disabled.c
6) Where needed, add a call to Process_Gyro_Data() in the *_spin() functions.
7) Enable the timer 4 ISR at the top of ifi_frc.h.
8) Make sure timer 4 is disabled at the top of timers.h.
9) Add calibration code somewhere like disabled.c/Disabled() (this requires that you use a mode dongle to emulate the field controller, which will put you in disabled mode for a period of time before transitioning to autonomous mode).
10) Do anything else I forgot to mention here <grin>.
11) Compile, test, calibrate your gyro (see gyro.h).

-Kevin

[Rindill]

Okay, I got a makefile working.

# Jeff Holland: 2/26/2005
# Manual makefile to go with Eclipse
# NOTE: enviornment variables must be set to find linker & compiler.
# NOTE: runs with GNU Make. Might also run with Microsoft nmake with tweaks.
#
# This Makefile will compile any .c file in the current directory and build the
# (PROJECT).hex file you can load in the robot.
#
# The OBJFILES variable is filled with .o targets using the wildcard
# command and patsubst. The $(wildcard *.c) will retrieve any .c
# file in the current directory and store it in a variable. The patsubstr
# functions is used to convert a file from one format to another. In
# this case each .c file is converted into a .o extension and then
# stored into OBJFILES. This variable is then used to compile each .c file.
# The rule %.o: %.c rebuilds any .o file if the cooresponding .c file has changed.
# In the compile line you will see two variables $@ and $<.
# $@ will match the target and the $< will match the dependency. So, for
# example, $< will contain main.c whenever $@ contains main.o.
# Note: makefiles are counterintuitive in that the rules don't run in the order
# listed in the file, but instead run whenever they are matched. Also be careful
# with tabs and spaces. Rules need a tab (not spaces) before each action.

#RENAME AS NEEDED
PROJECT=RR

#del for windows, rm for unix
RM := del /F

LIB_PATH=".;c:\mcc18\lib"
#MCC18_PATH=c:\mcc18\bin\

LINKER = mplink

CC = mcc18

PICFLAG=-p=18F8722

CFLAGS = -i".;C:\mcc18\h" -nw=2066

DEFINES = -D_FRC_BOARD

#optimization parameters (default = full optimization)
OPT_ENABLE_ALL=
OPT_DEBUG=-Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
OPT=$(OPT_ENABLE_ALL)

#make a list of object files that match all C files
OBJFILES := $(patsubst %.c,%.o,$(wildcard *.c))

COMPILE=$(CC) $(PICFLAG) $< -fo=$@ $(CFLAGS) $(DEFINES) $(OPT)

all: $(PROJECT).hex

#re-link if any object file changed
$(PROJECT).hex: $(OBJFILES)
$(LINKER) "18f8722.lkr" $(OBJFILES) "ifi_frc_8722.lib" /l $(LIB_PATH) /m $(PROJECT).map /o $(PROJECT).hex

# Recompile a file if it's c-file changes,
# OR recompile everything if ANY header file changes
%.o: %.c *.h
$(COMPILE)

#delete all the build files so you can start from scratch.
clean:
-$(RM) $(OBJFILES)
-$(RM) $(PROJECT).hex
-$(RM) $(PROJECT).map
-$(RM) $(PROJECT).lst
-$(RM) $(PROJECT).cod

[Kevin Watson]

Originally Posted by Mike Mahar

Is there some reason that you don't reset the sample accumulator to 0 in the first loop?

I just made this change (thanks Mike) and added some additional documentattion to the ADC and gyro code. Link is in message #1 of this thread.

-Kevin

[Jon236]

Kevin

still getting wierd compile errors.....
Clean: Done.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "autonomous.c" -fo="autonomous.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
C:\mcc18\h\stdio.h:26:Error [1178] illegal declaration of object of type void
C:\mcc18\h\stdio.h:27:Error [1178] illegal declaration of object of type void
C:\mcc18\h\stdio.h:31:Error [1178] illegal declaration of object of type void
Halting build on first failure as requested.
BUILD FAILED: Sun Jan 13 18:44:53 2008

????????

[Kevin Watson]

Originally Posted by Jon236

Kevin

still getting wierd compile errors.....
Clean: Done.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "autonomous.c" -fo="autonomous.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
C:\mcc18\h\stdio.h:26:Error [1178] illegal declaration of object of type void
C:\mcc18\h\stdio.h:27:Error [1178] illegal declaration of object of type void
C:\mcc18\h\stdio.h:31:Error [1178] illegal declaration of object of type void
Halting build on first failure as requested.
BUILD FAILED: Sun Jan 13 18:44:53 2008

????????

Send me your code and I'll look at it. Which compiler are you using?

-Kevin

[Jon236]

It's the ifi_frc_encoder_beta oput of the box....using the 3.10 compiler and 8.0 MpLab

[Kevin Watson]

Originally Posted by Jon236

It's the ifi_frc_encoder_beta oput of the box....using the 3.10 compiler and 8.0 MpLab

It builds just fine for me. Make sure the tool suite is set correctly and then use the project wizard to rebuild your project.

-Kevin

[Jon236]

Kevin,

I re-installed 3.10 and it worked just fine!

Thanks for all your work!

Jon

[Guy Davidson]

Originally Posted by Kevin Watson

Sounds like a fun project. I would not do my PID calculations in a ISR. Instead, I would set up a timer to fire off at 100Hz and then wait for the timer interrupt flag to go high and then do your PID calculations. The ideal place for this code is Teleop_Spin() and/or Autonomous_Spin(). Let me know if you have any problems.

-Kevin

Interesting. You're suggesting I run another timer at 100hz, and use one to time the calls on PWM() and the other one for timing the calculations, right?
I think I might have a simpler solution. I have the ISR that calls on PWM() to set another flag high (not the interrupt flag), and check that flag in the _Spin() functions. As a result, assuming the calculation runs fast enough, I'll be one cycle behind, which would probably be the case either way. Does that sounds like it could work?

Thanks.

[Lafleur]

Originally Posted by Kevin Watson

I just made this change (thanks Mike) and added some additional documentattion to the ADC and gyro code. Link is in message #1 of this thread.

-Kevin

In testing the code on my test system, this change to the ADC.c code made about 1% saving it time...

[comphappy]

Originally Posted by Kevin Watson

I just made this change (thanks Mike) and added some additional documentattion to the ADC and gyro code. Link is in message #1 of this thread.

-Kevin

I really appreciate what you are doing, and i don't mean to ask for more, but would it be possible for you to create diff/patch files when you release a new version, to make updating our code easier?

[comphappy]

Originally Posted by billbo911

I'm not sure I am following what the question is. If you have a PWM value that is going to be only one of two states, 0 or 255, then just test for one state. For example:

if (pwm03 > 127)
    {
      accumulator ++;
    }
else
    {
     accumulator --;
    }

I chose 127 just for simplicity.

Just as easily, you could test for the actual value.

if (pwm03 == 255)
    {
      accumulator ++;
    }
else
    {
     accumulator --;
    }

I was attempting to understand what the PHASE B was, i now know, and was just expressing how i was going to do it with out it in my specialized case. That code you wrote is exactly what i had described, and what has been in our code for a while now.

[billbo911]

Originally Posted by comphappy

I was attempting to understand what the PHASE B was, i now know, and was just expressing how i was going to do it with out it in my specialized case. That code you wrote is exactly what i had described, and what has been in our code for a while now.

It's nice to know that great minds think alike

I can, with 90% certainty, say that this year we will be using both of the GTS's and one quadrature encoder on our bot. Two for the drive, one for the "ball handler". Now, if the budget allows, we may go with three quadratures. (I hope, I hope, I hope )

[Kevin Watson]

Originally Posted by sumadin

Interesting. You're suggesting I run another timer at 100hz, and use one to time the calls on PWM() and the other one for timing the calculations, right?
I think I might have a simpler solution. I have the ISR that calls on PWM() to set another flag high (not the interrupt flag), and check that flag in the _Spin() functions. As a result, assuming the calculation runs fast enough, I'll be one cycle behind, which would probably be the case either way. Does that sounds like it could work?

Thanks.

My thought was to not even have an ISR and just keep an eye on your 100Hz timer interrupt flag with code located in teleop_spin() and/or autonomous_spin(). Just setup and start a timer, but don't set the interrupt enable bit to one, which will prevent the processor from calling the low priority ISR. Then with code like this in *_spin():

if(INTCONbits.TMR0IF)
{
// Get encoder counts

// Calculate position/velocity

// Do PID calculations

// Update PWM values

//reset interrupt flag
INTCONbits.TMR0IF = 0;
}

...you can implement your 100Hz contol algorithm.

-Kevin

[paulcd2000]

thank you kevin! i compiled, and everything checks out!