View Single Post
  #15   Spotlight this post!  
Unread 05-02-2007, 10:09
BradAMiller BradAMiller is offline
Registered User
AKA: Brad
#0190 ( Gompei and the Herd)
Team Role: Mentor
 
Join Date: Mar 2004
Location: Worcester, MA
Posts: 588
BradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant futureBradAMiller has a brilliant future
Re: Mixing WPILib with default MPLAB code

Quote:
Originally Posted by michael714 View Post
Dear Brad,
I've been trying to do it myself. I added the 2k5 files including API.h, UserAPI.h, and WPILIb2k5.lib to Kevin Watson's edu_camera code and the compiler was able to do everything with no errors or warnings except from the Linker at the end and it looked like this:

Error - section 'InterruptVectorLow' type is non-overlay and absolute but occurs in more than one input file.
Yeah, that's the crux of the problem. You are seeing that the default code and WPILib each want to control the interrupt vectors. It's pretty easy to write some code that tracks the green target using WPILib, but I think it would be some work to modify Kevin's project to be compatible. You would probably want to use the WPILib camera driver and have it deliver t-packets to his higher level code. It's kind of like trying to run LINUX and Windows on the same computer.

If you are interested in trying to port the code, I'd be happy to help in any way that I can.

WPILib (and easyC) have a different philosophy of device support from the default code, and Kevin's work is based on the default code. In WPILib all the interrupt handling and timing are handled from a single kernel much like an operating system. When other devices want to get interrupt support, either interrupt pins, serial ports, or timers, they just make calls to the kernel to register their "interest". Then when the interrupts happen, the kernal calls the interrupt service routines in the device driver. The reason it works this way is that the device drivers are completely independent of each other. So you could write your own camera driver while leaving everything else unchanged and you wouldn't have to change your application at all.

The default code doesn't work this way - it's a monolithic application that runs on the hardware. To add devices, changes mut be made to quite a few files, rather than just installing a new driver.
__________________
Brad Miller
Robotics Resource Center
Worcester Polytechnic Institute