New C18 3.0+ Compatible FRC Code
 

I've created C18 3.0+ compatible code and libraries for the IFI FRC robot controller. At this point the code is pretty solid and free of bugs. If interested, the code can be found here:

http://kevin.org/frc

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.

1/6/08 Edit: You need MPLAB 7.21 or greater to use the 3.0+ compiler. You can download the latest version here:
http://www.microchip.com/stellent/id...&part=SW007002

The student and upgrade versions of C18 3.10 (don't use 3.15) are here:
http://www.microchip.com/stellent/id...&part=SW006011

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

I like the layout....a lot cleaner than the present code template. Had a little problem compiling:
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "ifi_frc.c" -fo="ifi_frc.o" -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
C:\dev\ifi_frc_beta\ifi_frc.c:249:Warning [2002] unknown pragma 'tmpdata'
C:\dev\ifi_frc_beta\ifi_frc.c:250:Error [1020] unexpected input following 'interrupt'
C:\dev\ifi_frc_beta\ifi_frc.c:357:Warning [2002] unknown pragma 'tmpdata'

Suggestions?

Re: New C18 3.0+ Compatible FRC Code
 

I do like the layout better than the code from years past. A little less cryptic in function definitions, and file names. Although I do not know what the Disable_spin(), Autonomous_Spin(), and Teleop_Spin() are and what they would be used for.
Are their equivalents be Process_Data_From_Local_IO() just split up into different places??

Also I do like the addition of the check of the state to reset the outputs. Shouldn't this stop situations where you can only get one autonomous run from each hard reset?

I cannot confirm or deny any bugs on a compile. I have neither mplab nor mcc18 and only have a mac ;)

Re: New C18 3.0+ Compatible FRC Code
 

It's not backward compatible with the 2.4 compiler. I'll create a 2.4 friendly version if people like the layout. The update to 3.1 is available on Microchip's website:

http://ww1.microchip.com/downloads/e...-doc-v3_10.exe

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Yes, you're correct.

Shouldn't be a problem as long as the controller is sent to the disabled state first and you reinitialize your autonomous code. Perhaps I could provide a flag to let you know to initialize your code?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Is there any advantage to using the 3.0+ compiler?

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
I really like the structure of this code. It is MUCH cleaner and easier to follow. It will definitely help in teaching our newer programmers how to code specifically for FRC. I really like the use of the *_Spin functions. They make following and understanding the code and how it operates much easier, not only for new programmers, but also for relative Noobs to coding, like myself.

I see you are also taking advantage of the 3.0+ interrupt optimization capabilities. As we write ISR's will it be necessary to modify the way you are excluding the ".tmpdata"If I understood the included "C18 ISR.pdf", we should be fairly safe and not have to modify it at all, correct?



PS. I am really interested in making this code work with Vex if possible. I know this is a ways down the road, but it looks like it may just work. I'll keep you posted. I will wait to start down that road until the issues you pointed out are cleaned up first.

Re: New C18 3.0+ Compatible FRC Code
 

Thanks Kevin! The code is much cleaner and better documented than what ifi gives. The interrupts setup will be a great help to a lot of teams I am sure.

BTW, I have an updated version of my makefile to build this code if anyone is interested.
http://team997.org/files/software/Makefile_ifi_frc

Re: New C18 3.0+ Compatible FRC Code
 

Overall I really like to layout of the code. It looks a lot more intuitive than the IFI stuff.

I really like that the serial port, interrupts, timers, and PWMs, are already intgrated. That should save some time during the season.

The only issue I've got is the x_Spin functions. It seems to me that most of the code that I would run there would be the same regardless of the current mode. I believe that I would modify it to call just one function, and use the mode flags to change the few things that are different.

EDIT: I haven't compiled it yet, since I don't want to mess up my main dev box. Tonight I'm going to setup a VM with c18 3.15. I'll post if I have any issues then.

Re: New C18 3.0+ Compatible FRC Code
 

The more I read this code, the better I like it. I see you have included many of your "updated" functions as part of the base code. Thank you!!

I did note a couple things that may be a problem, but I am not certain because I am no expert when it comes to coding.

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


Just my $.02

Re: New C18 3.0+ Compatible FRC Code
 

The layout looks a lot more straightforward than the standard IFI. To address the concerns of those who would rather have a single Spin function, you always have the option of defining your own Default_Spin() function and calling it from each of the other Spin functions. I really think that choice comes down to six of one and a half dozen of the other. If you'd rather have a single spin function and switch inside of it on flags, you're duplicating the mode determining logic already defined in the main loop for the privilege of shoving all your spinning code into one large function. I don't think saving a function call to a Default_Spin() routine is really worth that hassle.

Re: New C18 3.0+ Compatible FRC Code
 

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 followed by "A lock violation has occurred". I can open the individual *.c and *.h files just fine.

Anyway, I've only just started looking through this and it already looks awesome! I really like the timer setup and interrupt handling setup. Last year I did some interrupt and timer stuff and it could get rather confusing; this will be great for our new, inexperienced programmers to get into interrupts without quite as much trouble. It is almost like if you took the logical layout and ease of coding interrupts from WPIlib and combined them with the lower level control of IFI's code. Great work, Kevin!

Re: New C18 3.0+ Compatible FRC Code
 

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

What did I forget?

EDIT: I moved it to a shallower directory, but it still returns that error.

EDIT: I uploaded a file with the output from the compiler.

Re: New C18 3.0+ Compatible FRC Code
 

Honestly, I don't think you did anything wrong. I believe a file or two were left out of the zip. If you'll notice, at the top of ifi_code.c is a "#include adc.h", that file is not included in the .zip.

Re: New C18 3.0+ Compatible FRC Code
 

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.

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?

Re: New C18 3.0+ Compatible FRC Code
 

Personally, I advocate doing this. I think keeping the teleop and autonomous sections separate is beneficial. If you have multiple programmers, it makes it easier for different people to work on different sections.

Additionally, I strongly advocate that everyone add a "robot.c/robot.h" that has all the robot functionality. This should be the only place that directly sets any PWM value. It would have functions like robot_drive(speed, turn_rate, gear) and robot_set_arm_position(height). These functions would be called from both the teleop and autonomous functions. Then, when you change your robot, swap motors around, change a pneumatic gear shifter to a servo gear shifter, bend a pin on the RC, etc, you only have one location where you need to make code changes.

Basically the robot.c/h file presents the robot conceptually to the rest of the code. The autonomous and teleop functions can deal with the logic, like "the robot drives forward X distance, and then turns 90 degrees", and the robot.c/h functions can translate that into "set PWM01=255, and PWM02=0".

Re: New C18 3.0+ Compatible FRC Code
 

Yes, this was considered, but I have a very small bias toward keeping the number of source files down to a minimum. Since most new teams probably won't touch the Autonomous( ) or Disabled( ) functions, adding four more source files would make the learning curve a little more steep. With that said, if we can reach some kind of consensus on this or any other aspect of the code, I'd be more than happy to modify the code to meet the needs of the community (which is one of the reasons I started this conversation).

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

What is your stance on pre compiling your drivers and back end code into a library? The source would be available to read, but you could cut out some of the mess in the source tree.

Although, on second thought, this may be a pain to maintain.

Re: New C18 3.0+ Compatible FRC Code
 

Just a bump. Still looking for the answer.

Re: New C18 3.0+ Compatible FRC Code
 

What version of MPLAB are you using? If it's anything less than 7.4 (I think), it won't work with the new compiler.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

No, it's a good idea and one I'm entertaining (e.g., I already have a version of ifi_frc_xxxx.lib with the serial port code included).

My interest right now is to make sure that the CD programmer community is okay with the architecture and, hopefully, will spend some time finding any bugs I've introduced. Once that's done, I'll have a look at simplifying the source tree.

Speaking of bugs, does anyone have any code which will consistantly cause the 8.3 volt problem? I have a theory I'd like to test out, but haven't been able to reproduce the bug.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

From my original post,


So, I thought it was 8.10, but now that I think about it, I originally installed 7.4 and the upgrade is only for C18, so I might still be at MPLAB 7.4, and C18 is 3.1. I'll verify when I return home this evening. Thanks Kevin! :)

Re: New C18 3.0+ Compatible FRC Code
 

From the C18 3.10 release notes: "MPLAB C18 v3.00 and later will not be compatible with versions of the MPLAB IDE prior to v7.21".

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Yep, you nailed it Kevin.

I had installed MPLAB 7.20, added C18 2.x then upgraded C18 to 3.10.

So, now that I have reinstalled MPLAB 8.0 with C18 3.10, it works like a champ! It loads and builds your project first time, every time.

Now I'm off to try and see if I can actually do something with it. :ahh:

Re: New C18 3.0+ Compatible FRC Code
 

Thanks immensely. I use C18 3.10 all the time, and its a pain to have to maintain two seperate development toolchains for general purpose and FRC specific code. It's great not having to go searching for that ancient C-BOT compiler disk whenever I need to set up a box for FRC code, when I can get the most recent MPLAB IDE and C18 from the microchip website.

Re: New C18 3.0+ Compatible FRC Code
 

We don't have a program that could run on a bare controller, but I believe that we still have our 2006 robot fully together (currently with a 2005 controller) and could put the 2006 controller and program back in it without much effort. I would not say that it "consistently" hit the the 8.3 volt bug, but it most certainly hit the problem frequently. If you have a patch in mind we would be willing to try it out during the build period. It would be really nice to fix that bug. We have sworn off using interrupts (in our own code) on the 8722 based controllers until the problem is addressed.

Eugene

Re: New C18 3.0+ Compatible FRC Code
 

Thanks. I'd be happy if I could just get a .map or .lst file of a build that exhibited the problem.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

I have sent you a web link to download a zipped example via a private message.

Eugene

Re: New C18 3.0+ Compatible FRC Code
 

I got the code. Thanks.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I noticed that you did not add the:

#pragma tmpdata low_isr_tmpdata

#pragma tmpdata

in the serial interrupts handlers?? but you did so in the timer.c and interrupts.c handlers??

is this an oversight??

thanks...

Re: New C18 3.0+ Compatible FRC Code
 

I wonder if Kevin's release of this updated code (albeit a beta version) implies that the IFI default code will also be heavily revised for 2008. If nothing else, I think it strongly implies that the canonical IFI RC/OI package will be in the KOP this year, even if it is the last time.

Alex

Re: New C18 3.0+ Compatible FRC Code
 

Yes, it certainly is. Thanks for catching it.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Or, given that Dave Lavery has the PsyOps and misinformation dials cranked up to eleven, you might consider that I could possibly be doing his dirty work by misleading everyone. Heck, for all I know, you could be working for Dave too and are planting counter-misinformation :D.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

I noticed this file does not include any encoder-related files. Are you planning to add support to encoders to this code?

Thanks.

Re: New C18 3.0+ Compatible FRC Code
 

It should be pretty easy to write your own encoder code with this architecture's method of handling interrupts. It would only take a few if statements and a couple of very short functions to read from a quadrature encoder. Much of the trouble with writing encoder code is configuring interrupts, and Kevin has already done that here.

You could basically copy and paste the code from the encoder driver's ISRs into the ISRs in this version (or put them in another file and call them from the ISRs, which would probably be more readable) and add the Get_Encoder_x_Count() function. Actually, if you just didn't call the initialization functions, you could probably use the current encoder code verbatim (well, for encoders one and two anyway, for 3-6 you'd probably just want to reuse the code from encoder 1-2 instead of the encoder driver's functions for encoders 3-6). I would say that it would probably be less than 20mins to code.

Re: New C18 3.0+ Compatible FRC Code
 

Great design. Just a word about words.

The *_Spin() functions are great -- it's just that in my little robot namespace world "spin" refers to when the robot turns around its axis. (We set up the joystick so one of the buttons calls the spin() routine that makes the robot turn on a dime.) When I saw "spin" that's what I thought it meant; I had to study the code to see what it really meant.

Is "spin" so standard in the embedded world that I should invent a new term for "turning on a dime"? (Diming? What if you only turn 90 degrees? Is that Quartering?) Or can we name the _Spin() functions something else? _WhileWeAreWaitingForNewData()? _StudyHall()? _Loitering()?

Sorry for the bad jokes, but I'm seriously concerned about overloading the term "spin"...

It just me?

Re: New C18 3.0+ Compatible FRC Code
 

In computer science a "spin loop" is a way to waste time while waiting for something to happen.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

If I get the sense teams will use the new code, I'll create versions with support for some sensors.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I noted that when I look at the .map file there is no reference to the low.isr.tmpdata in the map file ?? why is this?? I wanted to see how much space the compiler is giving to this... .tmpdata is there...

thanks...

Re: New C18 3.0+ Compatible FRC Code
 

The linker won't create the section if no temp storage is needed. Try enabling one of the interrupts and put this code in the interrupt service routine:

int a = 2;
int b = 3;
int c = 4;
int d;

d = (a + b + c) - (c + a);

Compile and then look at the .map file.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

In case we need that extra push over the cliff right about now :)

Alex

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

If you're looking for a head count for your template, count the TechnoTicks (236) in!

Re: New C18 3.0+ Compatible FRC Code
 

You could also probably count us (8) in too.

I have a somewhat related question that stems from encoders. How fast to digital inputs update? Is it the 26.6ms loop? Faster? I'm asking because I'm wondering about updating the encoder B channel. If it doesn't update fast enough, aren't we risking using an old value and so getting the wrong direction?

Re: New C18 3.0+ Compatible FRC Code
 

Treat the digital I/O as instantaneous. It's faster than the execution speed of the program instructions. What you read from an input pin is the state of the pin at that moment. What you write to an output pin takes effect immediately. There are measurable (but trivial) delays, but unlike PWM and relay outputs, there's no interprocessor software communication in the way to slow things down.

Re: New C18 3.0+ Compatible FRC Code
 

Very cool. Just what I was hoping to hear. Hopefully I'll have this new code driving a robot and looking at encoders before the week is over, and I'll be happy to give you (Kevin) any feedback or bugs I find.

Re: New C18 3.0+ Compatible FRC Code
 

We(1103) willl be using this code. So far it looks good.

Re: New C18 3.0+ Compatible FRC Code
 

Well in ver 3.10 of the compiler the .map file will NOT show an entry if there is no storage needed, but 3.15 will show a null entry. (as it should)

Re: New C18 3.0+ Compatible FRC Code
 

Hi Kevin.

Your new structure makes a lot more sense. I never liked the way the old code fell into the "autonomous" pit and never came out.

I installed MPLAB8 and upgraded to cc18 3.1. Other than the typical include/lib path issues asociated with any upgrade, your new code built just fine.

My own personal preference is to use more, smaller files, so my vote would be to split the auto and disabled modes out into sepparate files. I beleive that this would actually make it easier for teams not addressing these modes because they wouldn't have to keep scrolling arround the empty functions.

If you are lucky to have more than one programmer on the team, it does enable the "Autonomous" mode programmer to work somewhat independantly of the "teleop" programmer. Last year I also had c&h files for each of the four subsystems: UserIF, Drive, Manipulator and Vision, and assigned each subsystem to a student. It kept them out of each other's hair, and made it easier to see what had changed from version to version. Not much downside to extra files.

To Fill up the new files a bit, I would also vote for including the init_ functions. So, each of the mode files would have an init, spin and run function.

I also agree with the recomendation for teams to have a robot.h and robot.c file. It's the first thing I add to the standard ifi code. In my case this is where I put all my #defines for translating the cryptic I/O port names to robot functions, and code for enforcing various robot safety limits.

Team 1629 will definately be using your new code so I'm eager to see you fold all your other cool functions into this structure.

Phil.
A happy camper:D

Re: New C18 3.0+ Compatible FRC Code
 

Wow Kevin! I love it already. Everything is so well organized and everything is incorporated. This will be a really good tool for rookies as well as veteran teams :). I will definitely be using this on our 2008 robot :D

Re: New C18 3.0+ Compatible FRC Code
 

Just noticed this:

In your pwm_readme.txt file, you still reference Process_Data_From_Master_uP()

I guess this would now be: Teleop() and Autonomous(), although I see you make the call after these functions.

Phil.

Re: New C18 3.0+ Compatible FRC Code
 

Okay, I've implemented most of this. Is there really a need for a Disabled_Init( ) function?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Good question!

One way to look at it is:
During Competition, the systems boot up in Disabled mode. It wouldn't be a bad place to do some of the system initializations, Pre-calibrations and OI input gathering. Gyros would love the fact that the bot is not moving and compressors aren't running.

On the other hand, it is a bit redundant considering the Initialize () routine already exists in user_code.c.

Honestly, I say, give it the boot. (Yes, pun intended:ahh: )

Re: New C18 3.0+ Compatible FRC Code
 

Here is a snapshot of the current build:

http://kevin.org/frc/ifi_frc_beta_2.zip

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I would say it isn't. To my understanding (and the way I'd use it) the whole point of the disabled function is to initialize variables and do some setup. Hence, as far as I'm concerned, there's no need for an initializing function to the initializing function.

Re: New C18 3.0+ Compatible FRC Code
 

Checking our code for the last few years, we've had a Disabled_Init(), but mostly just used it for debugging. I think it's worth including, just for completeness. Similarly, each year we've had a Disabled_Spin() function[*], but it's always been empty. I think it's worth having all three functions (run, spin, init) in the framework for each mode.

[*] actually we called ours Disabled_Fast_Loop(); and the run function was Disabled_Slow_Loop(), but I think I like _Spin() and _Run() better.

Re: New C18 3.0+ Compatible FRC Code
 

Well as I understand it, you're still getting valid data from the OI in Disabled mode and teams have used this fact to select auto modes before matches start. So presumably, you'd want a Disabled_Init() to re-initialize this variable to a default value if you had to do a restart. I can see uses for it, but mostly I think it should be left in just for consistency between the different modes.

Re: New C18 3.0+ Compatible FRC Code
 

Okay, it's easy enough to do, but disabled mode is nominally called three times each round (before autonomous, between autonomous and teleop, and after teleop). Should Disabled_Init( ) be called each time, or only the first time? If only the first time, under what conditions would the default_init_flag get reset?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

It should be called only the first time and then reset on power cycle or on RC reset.
Just my opinion.

Re: New C18 3.0+ Compatible FRC Code
 

I would agree, but I am a person who likes to keep options open. With that goal in mind, I think it would be ideal to put the code that calls Disabled_Init() in an #ifdef conditional so a programmer can just quickly define/undefine something to change the behavior.

Re: New C18 3.0+ Compatible FRC Code
 

In answer to your initial question about the need for a Disabled_Init() function... we also used this to trigger calibrating the Gyro. The actual callibration only occured if we stayed in disabled mode for several seconds.

We put in the delay because we didn't know if the system transitioned through Disabled between auto and teleop. Based on your post, I'm glad we took that precaution.

We also did it for code symetry more than anything else.... Yes, I also indent all my "=" signs the same amount. Just call me anal.

I think the Disabled_Init() is most usefull once before the match begins, so that would mean that you wouldn't really want it called between Auto and teleop.

I thought that it might also be good to call it on the transition from Teleop back into Disabled (to indicate that there might have been a field reset situation after a bad start) but the bot is in an unknown state at that time anyway (maybe on it's side) so you wouldn't necessarily want to make any callibration assumptions.

In the end I guess this function would only be called after reset, so it is a bit redundant with Initialize(). Although, if the function is resetting variables that only get used in disabled mode, then my anal side says that that's where they should be declared and initialized :) This is also what we did with our UserIF, Drive, Manipulator and VisionSystem variables. Declared and initialized in subsystem modules.

Thanks for even considering it :rolleyes:
Phil.

Re: New C18 3.0+ Compatible FRC Code
 

That's looking excellent.

trivial note: I don't know whether you update your comments along the way, or once the build has stabilized, but I just wanted to mention that the ifi_frc.c file still has all the old reference to user_code.c in it's comments.

Another thing I realized when I loaded this project was that your development environment and mine don't match, so it caused a hickup that may trip up first time users (me two years back:)

You have the CC18 environment loaded under the MPLAB program folder, wheras mine is loaded under the c:/ root. I have no idea if this was a decision of mine, or the compiler default (i think so), or a consequence of me simply "upgrading" last year's install, but it means that when I load your project, two things happen:

1) MPLabs prompts me as to whether I want to keep my old CC18 compiler and Linker folders or use the ones in the project (I say keep the old one)

2) I get a linker error because MPLAB can't find the clib library. I need to go to Build-Options/Directories/Library, and set the path from c:/program files/mplab/cc18/lib to c:/cc18/lib

My only reason for bringing this up is to determine what you, and the likely "critical mass" of users will be using. If CC18 should be loaded under MPLAB then I'll move mine. If this is contrary to the install default, then a "pre-install" readme would be a good idea to prevent (minimize) the initial confusion of new users.

Thanks for all the time you put in.

Phil.

Re: New C18 3.0+ Compatible FRC Code
 

I believe it should be called every time that the robot enters into disabled mode.

Re: New C18 3.0+ Compatible FRC Code
 

Thanks. For now, I commented out the code for encoders 3-6, and I use the code for 1 and 2 by having the Int_1_Handler() in interrupts.c call on Encoder_1_Int_Handler() in encoder.c. This sounds like it should work, and I'll post here if it works or if it fails and I can't figure it out by myself.

How about gyros? I noticed that your gyro code from last year uses both gyro.c/h and adc.c/h. I copied both of thme, and I've been fumbling for a while with integrating them and timers.c. I have not been able to do that yet, generating a red-light-of-doom in the process. Any ideas or advice?

EDIT: Kevin, I believe I may have found a problem. Interrupts.h uses #define ENABLE_INT_# (for # being 1,2,...), while ifi_frc.c checks #ifdef ENABLE_INTR_# when checking for the ISR. That is an oversight, right? I searched the rest of the files and could not find another reference to ENABLE_INTR_#.

Re: New C18 3.0+ Compatible FRC Code
 

Another thought popped into my head about Disabled_Init(). The three times a robot gets disabled is true in most years games, but some years it happens a lot more. Remember 2005, every time the human player stepped off the enable mat to load a Tetra on a robot, that robot was disabled. So, with this in mind, the function would definitely need a flag that would only allow it to initialize on reboot or power up.

Re: New C18 3.0+ Compatible FRC Code
 

You might want to wait on the encoders as I have a scheme to make the encoder ISRs more efficient. I'll be coding it up sometime in the next few days.

I'll also port the ADC code too at some point (I need to find a better way of installing ISRs).

I'll look into the INTR vs. INT issue this evening. It's probably just some knuckle-headedness on my part. Thanks for catching it.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

How do you get a version 8 MPLAB? The disks that we've received from FIRST were all version 7.20. IFIRobotics' web site still claims that they only work with 7.20. I didn't notice the MPLAB requirement and now I have a hybred system that won't compile my 2.4 code nore will it open Kevin's new workspace.

Re: New C18 3.0+ Compatible FRC Code
 

www.microchip.com
It's free

Re: New C18 3.0+ Compatible FRC Code
 

MPLab v8 can be downloaded directly from Microchip.com.

I have had no issues running c18 v2.4 or v3.10 with MPLab v8.

Your 2.4 code will not compile with c18 v3, and the MPLab v8 workspaces will not open in older versions of MPLab. If you want to be able to compile your 2.4 code, you'll need to copy the mcc18 folder from a computer with 2.4 installed, and change the header, linker, and library serch folders of you 2.4 projects to point to the 2.4 folders.

Re: New C18 3.0+ Compatible FRC Code
 

Last year we got an updated adc code which only used 1 interrupt per sample, instead of 2. Is this already implemented in the new adc code? Also last year we had to use a new processor .h file for the encoders. I see the encoder work is in progress, so this will also disappear, I hope?

Isn't it new to be able to program for the disabled mode? Is there a hint there?

Re: New C18 3.0+ Compatible FRC Code
 

Previously the same code would be run in the robot was Disabled or Enabled. The outputs were just disabled.

Re: New C18 3.0+ Compatible FRC Code
 

Actually, you could always determine if the robot was disabled or enabled, the default IFI code just didn't make use of it and neither did most teams' custom code.

My team, and probably several others (I know Chief Delphi does it or at least did it at one point), implemented mode determination to help prevent integrator wind up in PID loops.

Re: New C18 3.0+ Compatible FRC Code
 

That's the only reason I ever did it.

Re: New C18 3.0+ Compatible FRC Code
 

Looking back at other posts, I see that now. It is nice for newer teams to see that they could initialize the gyro while siting and waiting for the match to begin. Now that is explicit. This newer code does look straight forward.

I won't get a chance to actually download this into a CD prior to kick off, but will spend my lunches studying it.

Thanks to all of you already solving problems!

Re: New C18 3.0+ Compatible FRC Code
 

I see there is a .lkr file 18f8520, does that mean I can play with it on a VEX bot?

Re: New C18 3.0+ Compatible FRC Code
 

No, you also need a version of the library for vex.

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

While we're looking at the new code, what is the difference between interrupts 1,2 and 3-6? I read the encoders readme, and I understand how they differ. However, I haven't seen any documentation about the interrupts themselves. Could you please explain me how (if it all) they differ?

Re: New C18 3.0+ Compatible FRC Code
 

Digital inputs 1 and 2 each go to separate interrupt circuits. They can be configured to cause an interrupt on either a low-to-high or high-to-low transition of the input. The interrupt service routine can inspect individual flags to determine which input caused the interrupt.

Digital inputs 3-6 all go together to a third interrupt circuit, and automatically cause an interrupt on any input transition. There's only one flag to say that "something changed" on those pins. In order to determine which of the four inputs is responsible, the software has to do its own bookkeeping to compare the previous input state against the present one.

That's a simple explanation. There's more detail in the PIC manual if you want it.

Re: New C18 3.0+ Compatible FRC Code
 

This makes sense. Thank you. I'll try using some of them soon, hopefully the ISRs in Kevin's code work as-is and then the difference won't really matter to me.

Re: New C18 3.0+ Compatible FRC Code
 

This evening I integrated a modified version of the ADC and gyro code into the new RC code and it seems to be very solid (while doing other things, including a bunch of printf()s, I have the ADC sampling at 6400Hz with no problems). The new ADC code uses the 8722s acquisition delay feature, which allows me to run it at one interrupt per sample, instead of two. I should be able to release it tomorrow.

This is next on my list.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Thanks for the link to Microchip. I went there three times and couldn't find it. The page looked like a sales page so I didn't scroll down and see the download links. Oh well. I've got it now.

Re: New C18 3.0+ Compatible FRC Code
 

Thank you Kevin for all of your hard work! I like what I see so far and I can assure you that team 34 will put this to good use.

Re: New C18 3.0+ Compatible FRC Code
 

Kevin:

Here are some change that I made to your serial routine to set the baudrate correctly for any processor speed.

in serial_port.c

#ifdef ENABLE_SERIAL_PORT_ONE
void Init_Serial_Port_One(void)
{
// Start by initializing the serial port with code
// common to receive and transmit functions
// SPBRG = BAUD_38400 ; // baud rate generator register [251]
SPBRG = SPBRG_VAL_1; // defined in hardware.h
//
#ifdef USART1_USE_BRGH_LOW
TXSTAbits.BRGH = 0; // high baud rate select bit (asynchronous mode only) [248]
#else // 0: low speed
TXSTAbits.BRGH = 1; // high baud rate select bit (asynchronous mode only) [248] // 1: high speed
#endif // 1: high speed


.................................................. .................................................. .................................................. ......


#ifdef ENABLE_SERIAL_PORT_TWO
void Init_Serial_Port_Two(void)
{
// Start by initializing the serial port with code
// common to receive and transmit functions
// SPBRG2 = BAUD_9600; // baud rate generator register [251]
SPBRG2 = SPBRG_VAL_2; // defined in hardware.h
//
#ifdef USART2_USE_BRGH_LOW
TXSTA2bits.BRGH = 0; // high baud rate select bit (asynchronous mode only) [248]
#else // 0: low speed
TXSTA2bits.BRGH = 1; // high baud rate select bit (asynchronous mode only) [248] // 1: high speed
#endif // 1: high speed





------------------------------------------------------------------------------------------------------------------------------------------------------------


in the hardware set up routines...




// Define system xtal/clock frequency
//
#define CLOCK_FREQ (40000000) // Frequency in Hz

#if defined(__18CXX) // All PIC18 processors
#include <p18cxxx.h>
#define INSTR_FREQ (CLOCK_FREQ/4) // PIC18 clock divider
#else
#error Unknown processor or processor not defined
#endif


// Set up serial port(s) baud rate
//
#define BAUD_RATE_1 (38400) // Serial port 1, bps
#define BAUD_RATE_2 (38400) // Serial Port 2, bps

// set as needed...
//#define USART1_USE_BRGH_LOW // for most lower baud rates
//#define USART2_USE_BRGH_LOW // for most lower baud rates

#if defined(USART1_USE_BRGH_LOW)
#define SPBRG_VAL_1 ( ((CLOCK_FREQ/BAUD_RATE_1)/64) - 1)
#else
#define SPBRG_VAL_1 ( ((CLOCK_FREQ/BAUD_RATE_1)/16) - 1)
#endif

#if defined(USART2_USE_BRGH_LOW)
#define SPBRG_VAL_2 ( ((CLOCK_FREQ/BAUD_RATE_2)/64) - 1)
#else
#define SPBRG_VAL_2 ( ((CLOCK_FREQ/BAUD_RATE_2)/16) - 1)
#endif

#if ((SPBRG_VAL_1 > 255) || (SPBRG_VAL_2 > 255))
#error "Calculated SPBRG value is out of range for current CLOCK_FREQ."
#endif

Re: New C18 3.0+ Compatible FRC Code
 

To be clear, without Kevin this would be miserable. Team 1622 is massively
in your debt. Thank you.

For those who have not already installed the MCC upgrade, make sure you put it in the same directory with the upgraded MPLAB 8.0. Otherwise the linker can't find the libraries. I know by the trying it the wrong way.

Re: New C18 3.0+ Compatible FRC Code
 

Rookie team 2605 will be using your code, it is structured in a way that makes more sense, I have not gone through it all the way yet, but so far so good. BTW is there a better search tool in mplab than the just straight basic find? For my embedded systems work I am always using grep and regexps, so far mplab has been really disappointing.

Re: New C18 3.0+ Compatible FRC Code
 

Comphappy,

The answer maybe Yes!

Try under the Project Menu > Find in Project Files.

Once you enter your keyword you'll be able to see the results in the output window under the find in files tab.

Double click on whatever you want to see and a new window will open with a pointer to your chosen element.

I hope this answers your question, as I'm not really sure as to what grep would deliver as a result.