New C18 3.0+ Compatible FRC Code

[Joe Ross]

Originally Posted by EHaskins

I just setup a clean virtual machine with Windows XP Professional sp2. I ran Windows Update, installed MPLab 8.0, and installed C18 3.15 Student Edition.

Here are the errors I'm getting:
MPLAB C18 v3.15 (demo)
Copyright 1999-2005 Microchip Technology Inc.
Days remaining until demo becomes feature limited: 60
C:\Documents and Settings\Eric Haskins\Desktop\ifi_frc_beta\ifi_frc_beta\ifi_code .c:31:Error [1105] symbol 'ADC_VREFPLUS_VDD' has not been defined
C:\Documents and Settings\Eric Haskins\Desktop\ifi_frc_beta\ifi_frc_beta\ifi_code .c:31:Error [1105] symbol 'ADC_VREFMINUS_VSS' has not been defined
Halting build on first failure as requested.
BUILD FAILED: Wed Dec 26 19:25:06 2007

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

[EHaskins]

Originally Posted by Joe Ross

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

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.

[Joe Ross]

Originally Posted by EHaskins

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.

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.

[Kevin Watson]

Originally Posted by EHaskins

What did I forget?

You forgot to read the readme.txt file .

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

[Kevin Watson]

Originally Posted by billbo911

If I understood the included "C18 ISR.pdf", we should be fairly safe and not have to modify it at all, correct?

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

[EHaskins]

Originally Posted by Kevin Watson

You forgot to read the readme.txt file .

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

oops

[Kevin Watson]

Originally Posted by billbo911

I noticed a couple "#include" statement for files that do not exist. For example, in "ifi_code.c" is a call to include "adc.h" and <delay.h>. I'm not clear on the differences when the "<xxxx>" is used, but it sure would be nice to have your "adc" code included.

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

[Kevin Watson]

Originally Posted by lukevanoort

I'm sure I'm just being stupid or something like that, but whenever I try to open the workspace I get a "Unable to open the workspace because the format of the workspace file has changed" error

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

[billbo911]

Originally Posted by EHaskins

I believe that headers within <>s are found in "c:\mcc18\h" by default. If you look adc.h, delays.h, and stdio.h, are all located there.

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.

Originally Posted by Joe Ross

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

Originally Posted by Kevin Watson

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

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.

[ay2b]

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.

[Kevin Watson]

Originally Posted by ay2b

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.

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.

Originally Posted by ay2b

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.

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

Originally Posted by ay2b

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.

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

[Mark McLeod]

Originally Posted by Kevin Watson

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.

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.)

[billbo911]

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"?

[Guy Davidson]

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.

[Tom Bottiglieri]

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?