Re: New C18 3.0+ Compatible FRC Code
 

adc.h should be included with the compiler. Are the include and library paths set? In the older MPLAB, the settings would be in project->build->project and would be:

C:MCC18\h for Include Path
C:MCC18\lib for Library Path

Re: New C18 3.0+ Compatible FRC Code
 

Both of those are set properly. Also removing the reference to <adc.h> creates other errors including; (2058)Call of function without prototype and more (1105)s symbol has not been defined. That suggests to me that the issues is not in the MPLab configuration.

Re: New C18 3.0+ Compatible FRC Code
 

Those are exactly the errors you would expect if it can't find the include and library paths. Since you removed the adc.h include, it wouldn't have the prototype for the adc functions (first error). The symbols not defined error is because it can't find the the adc library that defines those symbols.

Re: New C18 3.0+ Compatible FRC Code
 

You forgot to read the readme.txt file :rolleyes:.

Microchip messed up the adc.h file in the latest release. Either fall back to 3.10 (using the handy link I provided above) or just comment out the offending code as it is not needed and I will be replacing it in the near future anyway.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Yes, as long as you keep your code within the ISRs that I've provided in interrupts.c and timers.c, you should be fine.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

oops:o

Re: New C18 3.0+ Compatible FRC Code
 

Actually it's <adc.h> and <delays.h>. The <> tells the compiler to use it's own header files (usually in mcc18\h) instead of looking in the build directory. Once the code is stable and I have a sense that teams will want to use it, I'll build versions with support for some of my other code, like the ADC, gyro, encoder, etc.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

You'll need MPLAB 8.0 to open the project files. You can also just use the project wizard to create a new project.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

So I have learned.:)
Well, as long as I keep learning, I don't mind hanging it out there. At least now I know more than I did this morning.:D

That explains what I didn't understand. Thanks.

I am looking forward to the new builds that include your: ADC, gyro, encoder, PWM etc. I have learned a lot this summer by working with those versions from previous years and getting them to work with my Vex.
As of right now, I can fairly confidently say, we will use your code this year as long as the programmers don't decide to go with EasyC Pro. I need to let them make the choice.

Re: New C18 3.0+ Compatible FRC Code
 

This is great! I like the new architecture for the main loop - it matches what I've been advocating to teams for years. One additional change I'd recommend is to have a "Teleop_Init()", "Autonomous_Init()" and "Disabled_Init()" that gets called as soon as the new mode is entered.

I've been going through and comparing the old to the new, but perhaps you can give a more detailed explanation of the changes. Some parts I've gone through line-by-line, other parts I haven't had the time to do so yet. Here's what I've identified:

In _startup() you have some assembly labeled "initialize all memory to zero", whereas in the old code, there was a function Clear_Memory(), which presumably does the same. All the other startup & initialization routines appear to be identical.

The main() function is now better organized, so that it calls a separate "slow loop" and a "fast loop" function for each of the three modes - autonomous, disabled and teleop. The "fast loop" functions are *_Spin(). I might suggest having a suffix for the "slow loop" functions too, so you have Autonomous_Slow_Loop() rather than just Autonomous(), but that's just my style.

The serial_ports.[ch] code appears to be the same.

The comments in pwm.[ch] lead me to believe it is all new, but I do not have an old version around to compare. Historically, I've ignored the CCP pins and spent my time working on other programming problems.

The timer code is basically the same code (because it only takes a few lines to set up a timer), but is a bit better organized. My main recommendation here would be to use the provide OpenTimer and WriteTimer macros, where applicable, rather than setting the magic variables directly. Even with all the comments, I think those macros make it easier for people new to the PIC to understand what's going on.

The interrupt code is also better organized than before, though I haven't yet gone through it line-by-line.

What sort of changes were needed to make it work with version 3.1? I have not yet read C18_ISR.pdf, which may answer this question for me. My impression from the comments here so far is that the main difference is in the way the interrupt handlers are set up, so I want to make sure I really take my time going through the new interrupt.[ch] files.

Overall, I'm happy with the changes made. The overall architecture now more closely matches the overall architecture I've been using for my team, which means that when I find myself at an event helping some random with their code, based on this, I will have an easier job.

Re: New C18 3.0+ Compatible FRC Code
 

This was my original plan but I wasn't sure if the added functions would just confuse people. I mentioned earlier that a good compromise might be to raise a flag once the mode changes. I'd very much like to know how people feel about this.

My philosophy is to include all the code so folks can see what's going on.

Most of the work went into writing the interface library (ifi_frc_xxxx.lib) that's compatable with the new COFF file format used by the 3.0 compiler. I was actually ready to release the libraries last February, but ran into a nasty bug that kept the project on the back burner until a few weeks ago. I found the bug a few days ago.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I know what you mean about producing too many functions, especially in a single file. I have found it can muddle things for new programmers. In this case I think it can be handled with a flag in a couple of lines. Then we can teach the newbies how to make a function out of it.

EHaskins: The student version 3.15 can also be used if you fix the 3.15 version of the adc.h system file. There is a missing "#endif" at line 536. It does a series of PIC architecture checks and they forgot to close one conditional #if, thereby wiping out all the subsequent statements.

(I'm traveling in Va this week, so I won't be much help. I touch base (CD) when I can, which is actually more often than I expected to.)

Re: New C18 3.0+ Compatible FRC Code
 

OK, another noob question.
I installed a clean version of MPLAB the "upgraded" it with the file from the link Kevin provided.
I can't get it to open Kevin's ifi_frc.mcp. So, after using the Project wizard to create a new project, it will compile correctly without errors. Well, that's partially true, I had to comment out a printf statement in user_code.c.
Now the output window keeps spitting this out:
"Error: Bad magic number in COFF file "C:\TEMP\C18 3.0beta\ifi_frc_beta\ifi_code.o".
So, what is that telling me? What is a "magic number"?

Re: New C18 3.0+ Compatible FRC Code
 

Definitely very cool. Finally we're up to the times and there will be no need to dig up one of the old kickoff CDs every time we want or need to be able to compile code on a new computer. I'll definitely check it out soon.

Re: New C18 3.0+ Compatible FRC Code
 

I can't decide on whether or not I will split off the teleop, autonomous, and disable functions to their own files. I feel like user_code.c will be a bit cluttered and may be overwhelming for new student programmers.

Thoughts? Kevin, any reason you did not pursue something like this?