Re: New C18 3.0+ Compatible FRC Code
 

Thanks that is what I was looking for, still not very good, but better then what I had found. Grep is extreamly flexible long as you are willing to spend the time to learn how to use it correctly.

Re: New C18 3.0+ Compatible FRC Code
 

Here's a snapshot of the latest build:

http://kevin.org/frc/ifi_frc_beta_3.zip
http://kevin.org/frc/ifi_frc_gyro_beta.zip (with integrated ADC and Gyro code)

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

Is there any change log? So we can keep track of what's bew in beta 3? Other than, of course, the ADC and gyro in that version.

Thanks.

Re: New C18 3.0+ Compatible FRC Code
 

I know MPLAB can generate a makefile for you but those always seem messy so I wrote up a quick one to use for myself with Kevin's new code. Figured I'd share it here in case anyone else finds it useful.

Re: New C18 3.0+ Compatible FRC Code
 

Forgive my noobiness, but is that makefile what I need to develop on ubuntu? Set up c18 in wine, put the file in the directory with the code and do a make? Will that give me a loadable hex file? There was another makefile posted earlier that looked like it was made for Linux, should I use that?

Re: New C18 3.0+ Compatible FRC Code
 

Kevin:

Thank you. Thank you. Thank you. Team 832 (as well as other Georgia teams I help with their programming) will definitely make use of your new version.

All of the FIRST community is in your debt for helping all of the teams.

Mannie Lowe

Re: New C18 3.0+ Compatible FRC Code
 

I personally am not using it on Linux but if you change the path of the CC and LD to be the path to wine + the path to the executable, I would imagine it'd work for you no problem. Then you'd just change the value of RM to actually rm.

Re: New C18 3.0+ Compatible FRC Code
 

Great! Thanks! I hate working in a VM.

Re: New C18 3.0+ Compatible FRC Code
 

Thanks Kevin.

Being a new(ish) c programmer, it really helps with all of the useful comments and such. The code is very clean and organized which is always easier to read.

thanks again.

Re: New C18 3.0+ Compatible FRC Code
 

Hi,
I'm a freshman in my team, but i have a lot of C experience and was able to decrypt lasts years code. First of all I really like this layout much better. Is there bugs in the code to the point where i should not use part of it for the code this year. Also i know this requires a 3.0+ complier and i was wondering what complier the FIRST FRC controller is meant to work with. I might have this all totally wrong with complier versions because I am new to the complier and also to FIRST.
Thanks
1jbinder
Team 852

Re: New C18 3.0+ Compatible FRC Code
 

There certainly may be bugs but the chances of them not being found before ship is low (Remember with enough eyes, all bugs are shallow). I would think it is perfectly safe to use Kevin's new code on this years RC. The default code from IFI is years past is meant to compile with C18 2.4. I haven't seen this years default code but I suspect that is still the case.

Re: New C18 3.0+ Compatible FRC Code
 

The officially supplied version is 2.4, but a free upgrade to 3.10 (don't use 3.15) is available on Microchip's website. I haven't tested it yet, but the freebie student version will probably work just fine. For those who want to stick with 2.4, I just built a version that will work with the older compiler. After I do a bit of testing, I'll post a link to it.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Here's my first cut at C18 2.4 compatible code:

http://kevin.org/frc/ifi_frc_24_beta.zip
http://kevin.org/frc/ifi_frc_gyro_24_beta.zip (with ADC and gyro code)

Remember this is experimental code, so please do me (and everyone else who might use this code) a favor and let me know if you run into any bugs. Thanks.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Can I expect ADC and Gyro code for 3+ to be released soon(within the next week), or should I use the 2.4 version if I need that functionallity?

Thanks,
Eric

Re: New C18 3.0+ Compatible FRC Code
 

A link to it was added to the first message of this thread.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I really love the format! much cleaner and easier to use... Please tell me this will become the new standard!

On my only annoyed note: i wish i could see the Main files and Process_data_from_master_uP function. i get antsy if i can't see when everything's being called.

Also, i'd like to re-ask why i would use the Spin functions (maybe if i could see main.c, and i could see when they're bein called...)

Re: New C18 3.0+ Compatible FRC Code
 

The code you're looking for is located in ifi_frc.c.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Should I be using MPLAB 8 or the 7.2 that came with the kit of parts?

Re: New C18 3.0+ Compatible FRC Code
 

You should use MPLab 8 if you don't wan to have compatibility issues, but you can use 7.2.

Re: New C18 3.0+ Compatible FRC Code
 

Where can I get that?

Re: New C18 3.0+ Compatible FRC Code
 

Please define "that".

If you mean MPLAB 8.0 and C18 v3.1, please read the very first page.
If you are referring to MPLAB 7.4 and C18 v2.7, look in the KOP for the CBOT CD.

Re: New C18 3.0+ Compatible FRC Code
 

For people having issues with new MPLAB IDE and new C18 playing nice together:

When installing/updating your C18 compiler, (I went with 3.15 and am going to add the #endif that was mentioned earlier) there is a page of options after choosing which components to install that has the following:

[ ] Update MPLAB IDE to use this MPLAB C18
[ ] Update MPLAB IDE to use this MPLINK Linker, MPLIB Librarian, and MPASM Assembler

Check them! ;)

Re: New C18 3.0+ Compatible FRC Code
 

for the clib.lib error go to Project> Build Options> Project> Directories Tab. in the Show Directories menu, select library search path. delete the old one and create a new one where the clib.lib is located (a simple search on your computer should be able to find it). i dont know if you should but you can also do the same with the Linker-Script Search path, in which you should delete the old directory location and create a new one going to the lkr folder in your mcc18 folder. that should fix the problem :)

can someone point me in the direction of a tutorial in which i can use this code to program our new 2008 bot? also is there a way of reading the printf statements in an executed program without having to upload onto our robot?

Re: New C18 3.0+ Compatible FRC Code
 

If you take Kevin's simple code and just read it, there's a fair chance you'll be able to do the simple stuff (i.e. left joystick forward = left motor forward) by yourself pretty easily. Reading the aliases in ifi_frc and seeing that the joysticks are referred do as p1_y for the y-axis, for example, and that pwm channels are simply pwm01 through 16 also helps. Where you want to start writing code is the Teleop() function in teleop.c, as that is the function that is called upon receiving data in the teleoperated mode.

As far as prtinf goes, if you place your robot on blocks (so that the wheels are spinning freely and not touching anything) and you keep the programming cable connected to the computer, you will see the results of all printf's in the terminal window that pops up after you're done downloading code usinng IFI Loader.

Hope this helps.

Re: New C18 3.0+ Compatible FRC Code
 

I can confirm that as long as you make the change Mark McLeod described in this post. The C18 3.15 Student Edition compiler works just fine.

Re: New C18 3.0+ Compatible FRC Code
 

Hey, i really like the look! I'm having this problem when i try to compile:

how to fix?

EDIT: Fixed it (for anyone else, add the library file again (project menu) wherever you installed it)

now i'm getting:

Re: New C18 3.0+ Compatible FRC Code
 

The project file is messed up a little. I attached a zipped copy of the .mcp file for the gyro and non-gyro versions. Replace the existing one with that one, and it should work.

THIS IS .MCP FILES ONLY! NO CODE!

EDIT: Are you using c18 v3+ to compile the v2.4 code?

Re: New C18 3.0+ Compatible FRC Code
 

i believe i am. you download that from the microchip website? i have...
V 3.1

Re: New C18 3.0+ Compatible FRC Code
 

If you are using v3.1 you need to download the verison of the code for c18 v3+. It is listed on the first post of this thread.

Re: New C18 3.0+ Compatible FRC Code
 

i did download that one.

EDIT: oops... i didn't! Ok, well which of the various links is it? is it "the snapshot of the latest build"

Re: New C18 3.0+ Compatible FRC Code
 

The library file reference in the error you posted is the v2.4 version.(you can tell by the "_24" ending of the library file and the project directory) Unless kevin included the wrong library you accidentally grabed the wrong file.

The first three links are 3+. The other two are v2.4.

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

In the gyro.h file there are definitions for several different gyros. However, the new KoP gyro is not one of them. Do you think you will be able to add a set of constants for it next time you rebuild?

Thanks.

Re: New C18 3.0+ Compatible FRC Code
 

Sorry,

Not to drag everyone back to v2.4... but

Ive tried both a last years install and this years mplab v7.2 with 2.4 and it won't even open the 2.4 verion of the beta's project file.

There has been previous mention of mplab7.4 with 2.7.

This is not the version in our Canadian Kits.

Could we please clarify?

Re: New C18 3.0+ Compatible FRC Code
 

I believe the KOP gyro has the same sensitivity (the important parameter to match) as the ADXRS150, which is already supported. I'll look into it and get back to you...

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

All versions of the code have project files created with version 8.00 of MPLAB. You can either upgrade to 8.0 for free or just use the project wizard to create a new project. Sorry about the hassle, but it seems like every new version of MPLAP uses a different format for the project files.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Just grabbed both 2.4 versions and opened them up with MPLAB 7.62. I only had two issues.

1) The ifi_frc_8722_25.lib file was being displayed as "Not Found" even though it was in the root directory of the project along with all the other files. I just removed the "Not Found" version and added it back in the project.

2) Error during linking saying that the CLIB.LIB wasn't found. It was looking in c:\program files\mplab\mcc18\lib instead of c:\mcc18\lib. Very likely a configuration mistake on my part here. I just went in to the project properties and added the correct library path.

Compiled and linked without any errors.

Nice work Kevin.

Sean

Re: New C18 3.0+ Compatible FRC Code
 

I just verified the 2008 KOP gyro is 12.5 mV per degree/second, which is the same as the ADXRS150. The datasheet is attached.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Thank you very much. I'll hopefully be able to provide gyro and encoder code feedback soon.

Re: New C18 3.0+ Compatible FRC Code
 

I've finally been able to compile the 3.1 code, so I started looking over it. It seems that it's a lot cleaner than the past few years' code, but I'm used to those, so I've got a few questions. In the past few years we just put our processing of inputs on the joysticks in Default_Routine(). (This is probably not the best way to have done it, but oh well) I'm assuming we should put all of this code such as using the buttons and stuff into Teleop()? Thanks for the help, great code!

-Arty

Re: New C18 3.0+ Compatible FRC Code
 

Kevin:

In your beta code 3 you have two definition for timer 4, one in the timers.c with its ISR in interrupts.c and a 2nd in the adc.c code again with its ISR...

this maybe confusing for user...

thanks...

ps: there are a few typo still in ADC code, ie label is timer 2, but your code is timer 4...

Re: New C18 3.0+ Compatible FRC Code
 

I just spoke with the programming team tonight. We had to decide between EasyC Pro, MPLAB and IFI default code and the newer MPLAB and compiler with Kevin's new build.
I am happy to say, 2073 will be stretching their skills and using the new code and compiler.:D

Now I have a dilemma.
The team does not have access to a laptop, plenty of computers, but no laptop. So, they will have nothing to take with them to competition. I will not be able to join them at our regional either because of a previously arranged vacation in Hawaii. :yikes:
I do have a laptop I am willing to let them borrow, but it currently has my personal copy of MPLAB 7.2 and C18 v2.4 on it that I use with my personal Vex kit. I prefer not to uninstall it if I can avoid it. So, the question is, can MPLAB's 7.2 and 8.1, and C18's v2.4 and v3.1 co-reside on the same system?

Re: New C18 3.0+ Compatible FRC Code
 

There's a method to my madness (honest). The new scheme standardizes the ISR names across different code modules to make it easier for me to write code that just drops into someone's project without them having to enter the ISR code directly into their code. The downside is that they need to enable two #defines instead of one (see comments at the top of ifi_frc.h, timers.h and interrupts.h). There is also the possibility that two ISRs with the same name will be enabled, but the compiler will complain. I have another solution that uses linked-list ISRs and self modifying code, but I decided it might become a support nightmare, so I'm not going to release it.

Thanks. I'll go code splunking and fix 'em

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Yep. You can also call IFI's old default_routine(), which has been moved to ifi_code.c.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I installed 2.4 and then made a copy of the entire mcc18 directory. I then applied the 3.10 upgrade to the original 2.4 directory. Now I can use both compilers and all I have to do is make sure the correct directory is named "mcc18" at build time (thanks go to Mark at IFI for pointing this out to me).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Excellent! Got it running!!
Next question. You currently have 3 versions for 3.0: Basic, Basic + Gyro, Basic + encoders.
To add the encoders to the basic + gyro, do I just add the encoder.h/c files to the project? Then follow your instructions for adding your encoder code from an earlier build, like 2007's ifi_encoder.zip?

Re: New C18 3.0+ Compatible FRC Code
 

It should be a matter of:
1) Adding encoder.c/.h to the project.
2) Putting #include "encoder.h" at the top of each source file where any encoder functions will be called.
3) Calling the encoder initialization function(s) from teleop.c/Initialization().
4) Enable the individual encoder channels at the top of encoder.h.
5) Assign the encoder phase b signals to digital inputs at the top of encoder.h.
6) Enable the interrupt(s) associated with each enabled encoder channel at the top of ifi_frc.h.
7) Make sure there are no conflicting ISRs enabled at the top of interrupts.h.
8) Compile and test.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

Did anything turn up on your inspection of the provided
code with respect to a possible source of the 8.3 volt bug?

With all the interrupts we will have flying this year,
we are sweating it, although we will get a good six
weeks to see if it surfaces again.

Eugene

Re: New C18 3.0+ Compatible FRC Code
 

While testing the new library code, I discovered that I could induce the 8.3 volt bug pretty reliably (I had never seen it before), and more importantly, eliminate it by initializing the entire RAM array to zero at boot time (something the C18 startup code does not do and IFI only partially does). I need to get in with a hardware debugger to see what's going on, but I haven't had time to build the custom cable I need to use the internal debugging header. I hope to get to it sometime in the next week.

If it's of any interest, I did notice the new code and compiler seem to handle high interrupt loads better than with the 2.4 compiler. I setup my ADC code to sample at 6400Hz (each sample generates an interrupt) while generating a few hundred more interrupts/sec with a encoder. The RC had no problems sending a bunch of telemetry using printf() under the load.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Although Kevin already responded, I felt I should say how I did it. I found a freeware diff utility for windows and compared the two folders, and I used that to see the changes and add one to the other. It worked pretty flawlessly and also helped me integrate the two test teleop() routines.

Re: New C18 3.0+ Compatible FRC Code
 

Awesome, thanks a lot Kevin!

Re: New C18 3.0+ Compatible FRC Code
 

Does this mean that the resolution that IFI published to "fix" the 8.3 volt problem does not work. They recommend changing a high chuck of memory (0xF00 - 0xF5f) to "PROTECTED".

Re: New C18 3.0+ Compatible FRC Code
 

No, that's not what I'm saying. Clearly the "fix" does work because I don't think anyone has seen the 8.3 volt problem since IFI published the new linker script.

I just thought it was interesting that a bug in my code could induce the same symptom that teams saw two years ago. Although I know how to fix it, I'm not sure I know exactly what caused it. For my own edification I'd like to track it down because it's not obvious to me what is causing it by examining the source code.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I have complete faith in your ability to find the root cause! But, until you do, and because you know how to fix it, can you share with us how to fix it so we don't run into it until the final fix is released. From your prior comments, it sounds like we just need to completely clear the RAM on reboot. Could we make the changes to our projects to do this, or would it just be easier to replace a particular file with the mods in it already?

BTW, I fully understand your need to know exactly why this problem happens and just knowing how to fix it isn't enough. ;)

Re: New C18 3.0+ Compatible FRC Code
 

As far as I can tell, there are no bugs in my code. The bug I referred to was fixed long ago and the fix incorporated before I released any code. If interested, it's the six lines of assembly under the "initialize memory to all zeros" comment in ifi_frc.c/_startup().

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Ahh, got it. Your code has this problem corrected already. The error was in older code. COOL!!! I feel better already!

Re: New C18 3.0+ Compatible FRC Code
 

There seems to be something amiss when using the combination of MPLAB 8.0, C18 V2.4, the V2.4 beta code and the MPLAB SIM debugger. I think that's a "legal" combination, right? The simulator seems to be going off into the weeds when it hits line 373 (serial port enable) of serial_ports.c. The odd thing is that if you step through it it hangs up on that line, but if you let it run it instead hangs up on line 427 of ifi_frc.c, which is _do_cinit();

Is this just a question of the beta code not supporting MPLAB SIM? I don't think I've seen any _SIMULATOR definitions in either the 2.4 or the 3.1 beta code.

Edit: The same thing happens when I run the 3.1 beta code with C18 v3.1. Maybe I'm the only one trying to use MPLAB SIM? It worked like a champ with last year's code.

Re: New C18 3.0+ Compatible FRC Code
 

The IFI "fix" did not help the instance of the 8.3 volt problem
that we ran into using the 2006 controller in the game Aim High.
If may have helped some teams, but it did not fix things
for us and I am aware of some other teams that it did not fix
the problem for as well.

We will happily try zeroizing all of memory at startup if we
see 8.3 showing up in the voltage display during this build season.

Eugene

Re: New C18 3.0+ Compatible FRC Code
 

Ugh, I spoke with IFI last week and they're of the opinion that the 8.3 volt bug has been fixed. If this bug bites you again, please let IFI know (and if you don't mind, me too).

Open up ifi_startup.c and replace the call to Clear_Memory() with this code:

// initialize memory to all zeros
_asm
lfsr 0, 0
movlw 0xF
clear_loop:
clrf POSTINC0, 0
cpfseq FSR0H, 0
bra clear_loop
_endasm


-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I did talk to IFI last year, after seeing the bug. However, they were busy fixing radios at that time. There was at least one other team with the problem as well.

You can read about what I found in this thread, starting at post 133. http://www.chiefdelphi.com/forums/sh...t=44954&page=9

Re: New C18 3.0+ Compatible FRC Code
 

I am currently in the process of testing the old configure.py makefile with this new code. Has anybody had success?

I use a mac, and seriously do not want to try and update mplab in vmware.. painful memories..

Re: New C18 3.0+ Compatible FRC Code
 

Our mistake here is probably very silly and obvious, but the solution eludes us nevertheless.

We're trying to get the gryo and accelerometer working, but we get a build error when we try to use the Get_Analog_Value function.

The build error we get is:

I've gotten as far as the fact that rc_ana_in16 is aliased to ADC_CH15, but no further.

Re: New C18 3.0+ Compatible FRC Code
 

I am trying to figure out the encoder code, and do not understand how the code knows what way the shaft is turning,
void Int_1_ISR(void)
{
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}

What really is ENCODER_1_PHASE_B_PIN?
And what port is this interrupt running one Input 1 or 2?

Re: New C18 3.0+ Compatible FRC Code
 

When using a "Quadrature" encoder, there are two signals generated, Phase A and Phase B. Both are square waves with "B" 180 degrees out of phase from "A". When triggered by "A" going high, the ISR looks at "B", if it is low, you are going forward, if "B" is high you are going backward.
In the code it explains how to attach the A and B phases.

Now, if you are not using a quadrature encoder but one with a single output, like the GTS in the kit, then determining direction is a much bigger challenge although, not impossible.

Re: New C18 3.0+ Compatible FRC Code
 

Open up encoder.h and have a look at the comments for the answer to what ENCODER_1_PHASE_B_PIN is. Rotation direction is determined by the logic state of phase b on the rising edge of phase a. Have a look at this illustration for a diagram showing what the waveform looks like. If the encoder were spinning in the opposite direction, the phase b waveform in the illustration would be flipped top to bottom.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I got what port it was hooked up to, I was just trying to figure out what phase b was, as the GTS does not have one, I will just modify the code so that instead of looking at phase b it will look at the PWM > or < 127 to determine the correct operand. I just need to determine the distance travailed on the linear drive.
Thank you for the diagram it was really useful. (BTW I like your code, it is clean and well organized)

Re: New C18 3.0+ Compatible FRC Code
 

The simple answer is don't use Get_Analog_value. The new code in adc.c should replace it. Instead you should call Get_ADC_Result. Make sure you set NUM_ADC_CHANNELS to the number of analog inputs you are using and allocate them starting with first one and go up from there.

The analog inputs are not instantaneous. You have to start them, then wait a certain amount of time and then read them. The code in adc.c will do that for you and uses a timer to wait. Calls to Get_ADC_Result will simply fetch the result that the library has already captured for you.

The function Get_Analog_value does the start/wait/read operation in-place and takes longer and consumes valuable cycles that could be put to better use doing something else.

Re: New C18 3.0+ Compatible FRC Code
 

Kevin, I have question about adc.c.
In Timer_4_ISR you have two for loops that cover the same range of indexes.
Is there some reason that you don't reset the sample accumulator to 0 in the first loop?
I'd think that any cycles saved in an ISR is a good thing.

Re: New C18 3.0+ Compatible FRC Code
 

I have used this method in the past on my Vex bot. It works fairly well but is not perfect. For use in straight line driving, as in Hybrid mode, it should be sufficient. BTW, make sure you account for the dead-band associated with the Victor.

Re: New C18 3.0+ Compatible FRC Code
 

There have been at least two makefiles posted in this thread.

Re: New C18 3.0+ Compatible FRC Code
 

Beats me. I'll have a look at it when I get home from work.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin:

An idea...

A quick and dirty utilizations counter...

Add a global long integer to you project called "cycle". At the end of the while(TRUE) in main.c, do a cycle++ to build a loop counter, this will tell you how many time you have been in the while(TRUE) loop.

In the 26.4ms loop, read the cycle counter, clear it and divide by (264k clock cycles, the number of clock cycles in 26.4ms - the number of cycles used in the while(TRUE) ) This will give you a crude % utilization of the CPU that the teams can use to check on there code efficiency...


also, the counter could be scaled so that one could use an unsigned int

Re: New C18 3.0+ Compatible FRC Code
 

how exactically are we supposed to build in 7.21 with the c18 3.10 and now i can't just push F10 to build.

edit:

also when I open it it does not open correctly when I try to open the project files.

Re: New C18 3.0+ Compatible FRC Code
 

How do you allocate the analog inputs with Get_ADC_Result? I found where to set NUM_ADC_CHANNELS, but I haven't found anything about allocating specific inputs. Furthermore, what is used as the argument of Get_ADC_Result?

Re: New C18 3.0+ Compatible FRC Code
 

an error in my logic....

you also need to take the number of loops and multiply by the number of cycles in the loop and use this to subtract from the total number of cycles in the 26ms...


tom lafleur

This is the code I did in a TEST module with only the ATD and Serial ports, I have a timer that interrupts me ever 100ms. I disable all interrupts and use the MPLAB simulator to measure the number of cycles in the main loop. In my case it was 42 cycles. Note, division is only by 10,000 and not 1,000,000 to give a % with out the need to multiply by 100, saving some cycles.

int util;
long int cycle = 0; is a global in the code, it needs to be long because of the multiplication need a long

in the main loop I have a cycle++;

// here we will calculate the % of the CPU we are using
// we are here every 100ms, that 1,000,000 cycles of the processor at 40MHz
// utilization = the number of times in the do nothing loop, * the number of cycles in
// the main loop. 42 is current number of cycles in main loop

util = 100 - ((cycle * 42)/10000);
cycle = 0;

Re: New C18 3.0+ Compatible FRC Code
 

Cool. I've been thinking about adding a few cool features like a system clock (uS?, mS?, real time?) and scheduler. Perhaps I should start another thread for wish list items?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

A Makefile (forced to call it Makefile.txt to upload) for Linux in included. I'm using cxoffice (a canned wine setup) but it can be easily altered to work with plain old wine or to run under Windoze. This compiled Kevin's latest stuff with no errors but with a bunch of signed/unsigned warnings. I have not run the code on the robot yet!


Enjoy

Re: New C18 3.0+ Compatible FRC Code
 

Hi,

EDIT - We've got a working install of mplab 8.00, but we can't seem to get 3.00 installed. We run through the installer fine, but it doesn't seem to actually install.. MPLAB is still using 2.40, and we can't find the installation directory of 3.00 - only 2.40.

I'm trying to install mplab 8.00 and the 3.0 compiler, I downloaded the software on the first post, and the tried running it over the install of mplab 7.20. It seemed to install, but now when ever we open mplab it says 8.00 is not enabled, but we can still use 7.20. How is the best way to install it and the compiler with pre-existing versions all ready installed?

Re: New C18 3.0+ Compatible FRC Code
 

Kevin, First of all thanks, this will be a great help.

Our team has a 2005 robot controller and operator interface mounted to a board for testing purposes when it is not practical to use the current robot controller (e.g., the current controller is on the robot, and the robot is being built or modified). We swapped out the libraries and linker files for the ones corresponding to the PIC18F8520, changed the target to the 8520, and tried to compile. We got this error(in your ifi_frc_gyro code, if it's relevant):
inaccuracy

The line code corresponds to
Any ideas? We couldn't find ifi_analog_channels in either .lib file. What would your suggestion be?

Thanks,
James

Re: New C18 3.0+ Compatible FRC Code
 

CPU Utilization

In a quick test I did today, using a ATD sample rate of 200Hz, I had 19% utilizations of the processor. Changing only the ATD sample rate to 6400Hz, utilization went to 43%.

Re: New C18 3.0+ Compatible FRC Code
 

Replace "ifi_analog_channels" with "ADC_15ANA" and it should compile.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I just tried it here and you probably need to add this line at the top of the file: "#include <adc.h>". You can also just comment out the line and compile. On my to do list is replacement code for this function.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
Thanks - we already had #include <adc.h>, it seemed to come like that. Our mcc18 adc.h file actually did not have a definition for ADC_15ANA - it had 0-14 and 16. Assuming the intent is to set all the pins to analog, I changed "ifi_analog_channels" to "ADC_16ANA" if it helps.

In our file, we had
Weird, eh?

Thanks again,
James

Re: New C18 3.0+ Compatible FRC Code
 

Looks like their library documentation is messed-up. Use ADC_16ANA.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Using new code with Eclipse? How to make the correct makefile? Help?

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
I am currently working with the ADC and Gyro code for the mcc18 v3, using MPLAB IDE v8.0. I realized that I had v2.4 of the compiler, so I downloaded and ran the v3.1 updater. Now, when I compile, the linker tells me I have the wrong (out of date) COFF file format for the object files (*.o). Any ideas?

Here is the error:
-Ethan

Re: New C18 3.0+ Compatible FRC Code
 

Try using the "build all" option, which will recompile all source files before linking.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I am planning on using the custom pwm.c/h code to generate the two pwm signals at 100Hz. I realized that unless I am also providing command and mointoring the system at 100Hz, it won't gain me anything (i.e. if I were to generate pwm commands in the 38Hz loop and update the commands at 100Hz, I don't think I'd gain anything). Hence I am also planning to update encoder-based pid loops at a rate of 100Hz. Not only this will give me a constant interval between updates, making my velocity estimates more reliable, it should make use of the faster update rate by generating commands at that rate.

Will doing something like that impact the performance of the the pwm functions? My PID loop code is not much more than a bunch of logical tests and integer multiplications. I am wondering if I should be okay if I call the PID code from within the Timer ISR that generates the pwm signal, or am I risking a significant drop in performance.

Thanks (and I hope my question is worded clearly enough - if not, please let me know, and I'll try to reword it)

Re: New C18 3.0+ Compatible FRC Code
 

This is related to the Beta code, but with default code compiled with MPLAB 8.00 and c18 2.40 I get a similar error to Etahn Reesor:
Any idea on how to fix this?

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

I keep getting a link error
Error - could not find definition of symbol 'Int_6_ISR' in file 'C:\dev\ifi_frc_gyro\ifi_frc.o'.
even when I enabled interrupts 3-6 in ifi_frc.h

Thoughts?

Re: New C18 3.0+ Compatible FRC Code
 

The linker can't find the Int_6_ISR() function in your source files. You need to perform step #4 in the list and enable encoder #6. If this doesn't solve your problem, can you send me your code (I hope I haven't done something knuckle headed)?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

All my problems went away when I downloaded you encoder_beta version.

Re: New C18 3.0+ Compatible FRC Code
 

Yes, I am aware of that, but in this case the PWM is being driven with out any user input, should be ether 0 or 255, nothing in the middle.

Re: New C18 3.0+ Compatible FRC Code
 

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:

I chose 127 just for simplicity.

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

????????

Re: New C18 3.0+ Compatible FRC Code
 

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

-Kevin