Log in

View Full Version : Multiple .cpp files in Windriver


divisionByZero0
06-02-2011, 21:52
The basic structure of our team's code was to have multiple .cpp files in the same project. Each .cpp was a custom Class for each component for our robot.

The problem was that our robot will refuse to load its own code.
:eek: :eek: :eek: :eek:

My theory about this was the compiled .o files were not compiled in the correct order in the .out program for the CRIO's bootloader to recongize our main robot's code. Does anyone knows if the .cpp file for our main robot codes should be compiled before or after every other .cpp file? Or does the order of how each .cpp into the .out code shouldn't matter?:confused:

demosthenes2k8
06-02-2011, 22:23
Normally, the .cpps can be compiled in any order, since they'll all be linked together in the end.

jhersh
08-02-2011, 03:27
It is also true of the cRIO. The linker runs after each file is compiled. Any unresolved symbols are resolved by the loader at runtime. If the loader can't resolve them, then you get an error.

-Joe

Bongle
08-02-2011, 07:00
If you haven't already, use the "target console" in windriver or the serial output on the cRio to find out what symbols aren't loading.

Make sure you're using matching versions of the cRio image (v27, for example) and WPILib.

Make sure that all your CPPs are added to windriver and are actually getting compiled (easy test: insert compile errors in them and see if you fail to build your project). Having a definition in a .h file but forgetting to include the cpp will allow you to compile, but it'll fail once it is on the robot.

divisionByZero0
10-02-2011, 00:19
Thanks for the advice...
That problem was easily resolved....


..... but now we have a new problem :confused: :yikes: :ahh: :mad: :D
Our team-coded classes are failing to initalize some components.
Each time these components are called, The cRIO freaks out and
reboots it self. So please, just a few more questions:

How "Bug-less-ly" can you initalize a WPILib C++ object via.......
Object i.e: Victor myVictor(...)
vs.
Pointer i.e: DigitalInput* myDI = new DigitalInput(...)

What are all the possible program exceptions to look
for that relates only when initalizing the object?

If we were to put them in a custom C++ class that
our main robot will use, of which that custom class will hold all
of the required group of electronic objects of the special component
on the robot that custom class is made for; What would be a nice,
error/exception free example for this? (Sorry if you see this as a run-on)


Our team has the recent updates for Windriver, the cRIO, and the
Driver Station. So we don't think those shouldn't be the problem.

Please, help us.....

Thank you all in advance,
And thank you everyone else who helped us on this topic so far.....

Bongle
10-02-2011, 07:28
What we typically do is instantiate all our component pointers in the Robot constructor, then pass them into the sub-controller classes.

Example: Let's say my robot class is Robot2702

class ArmController2702
{
public:
ArmController2702(Victor* pClaw, Victor* pArm, Encoder* pArmEncoder) : m_pClaw(pClaw), m_pArm(pArm), m_pEncoder(pEncoder) {}
};
class Robot2702
{
public:
Robot2702()
{
clawMotor = new Victor(1,2);
armMotor = new Victor(3,4);
armEncoder = new Encoder(5,6,7,8);
armController = new ArmController2702(clawMotor, armMotor,armEncoder);
}
void OperatorControl() {}
void Autonomous() {}
};


Checks:
-It's a good idea to pass objects in or instantiate them in the constructor. That way, you know they're there before you start using the class.
-To figure out what's going on, I believe there is a function you can use called wpi_fatal which will halt execution. You could use it like this
if(armEncoder == NULL) wpi_fatal("oh no, our arm is missing!");
then watch the output in the console to see what's going on
-Make sure your battery is full. A low battery can cause the robot to reset once a motor draws current and drops the voltage too low.

divisionByZero0
14-02-2011, 23:42
Works perfectly!!!!!!

Thank you so MUCH:D :D :D