Compressor Code causes No Robot Code Error

[gvarndell]

Originally Posted by jhersh

Just to be clear, you are referring to the "FRC Default Program" (as listed in the examples) aka "BuiltinDefaultCode" (as listed in the Project Explorer)? I double checked this project and it definitely includes the -mlongcall option.

Can you speculate what update we might be missing that would cause us not to have it?
I actually did a dump of the relocation data from the elf file after building it and there were a bunch of RELOC_24 in it.
After I added -mlongcall and rebuilt, they were gone -- replaced by pairs of RELOC_16 as you would expect.
The only thing I'm not 100% certain is what sample project I used.
I'll have to check my 'robotics' computer when I get a chance and see which sample it was.

[sircedric4]

The example I used was Iterative Robot Demo Main Program. We just performed the magic -mlongcall chant and did the appropriate ritual and the robot now functions as expected.

We are trying to figure out why our encoders themselves don't give us data, but we're just starting that. We are checking our wiring first again, and checking the forums, and then checking the code that's already posted above. The good news is that the Compressor code performed flawlessly after we got the Reallocation error gone.

Thanks, and any suggestions on encoders would be appreciated though I may start a new post for that after we give it a good effort tonight.

[jhersh]

Originally Posted by gvarndell

Can you speculate what update we might be missing that would cause us not to have it?
...
The only thing I'm not 100% certain is what sample project I used.
I'll have to check my 'robotics' computer when I get a chance and see which sample it was.

Really the only thing I can think of off hand would be if either one of the projects doesn't have that option set by default and that's that you started with... or that you created the project from scratch. That option should have been set in all examples since last year.

[jhersh]

Originally Posted by sircedric4

The example I used was Iterative Robot Demo Main Program. We just performed the magic -mlongcall chant and did the appropriate ritual and the robot now functions as expected.

I don't even see that one. Perhaps that's the problem. If there are really old examples left laying around since last year, it's possible the example had a bug in the project from back then.

This is the list of projects that I see in source control today:

2010ImageDemo
BuiltinDefaultCode
CameraDemo
CSimpleTemplate
DashboardDataExample
DefaultRobot
DriverStationLCDText
GyroSample
SimpleTemplate
SimpleTracker
TwoColorTrackDemo

Anything you have in addition to these is probably very obsolete.

If I had a recommendation, it would be to remove all of the projects in the C:\WindRiver\workspace\WorkbenchUpdate\vxworks-6.3\target\src\demo directory and then install the C++ update.

Originally Posted by sircedric4

We are trying to figure out why our encoders themselves don't give us data, but we're just starting that. We are checking our wiring first again, and checking the forums, and then checking the code that's already posted above. The good news is that the Compressor code performed flawlessly after we got the Reallocation error gone.

Glad it worked for you. As for encoders... first things first make sure that, as the wheel spins, both lines change by adding a Get() on each of the two DigitalInput objects. Then pass those DigitalImput objects into the Encoder constructor.

[sircedric4]

Originally Posted by jhersh

I don't even see that one. Perhaps that's the problem. If there are really old examples left laying around since last year, it's possible the example had a bug in the project from back then.

This is the list of projects that I see in source control today:

2010ImageDemo
BuiltinDefaultCode
CameraDemo
CSimpleTemplate
DashboardDataExample
DefaultRobot
DriverStationLCDText
GyroSample
SimpleTemplate
SimpleTracker
TwoColorTrackDemo

Anything you have in addition to these is probably very obsolete.

If I had a recommendation, it would be to remove all of the projects in the C:\WindRiver\workspace\WorkbenchUpdate\vxworks-6.3\target\src\demo directory and then install the C++ update.



Glad it worked for you. As for encoders... first things first make sure that, as the wheel spins, both lines change by adding a Get() on each of the two DigitalInput objects. Then pass those DigitalImput objects into the Encoder constructor.

It turns out its extremely helpful if you actually tell the encoders to Start() in your code. :-) Like I said we hadn't gone through the code yet and seen what our errors might be. Once we dug into the encoder header it became pretty obvious what to do. They give us numbers now when we call the Get() method. In the WPI User's manual they don't mention anything beyond setting them up. I guess they leave the using them up to the user. Not sure what we'll do with them yet but having the number there to deal with was the important bit right now.

As for the code, I moved my entire last years Windriver directory over to a new directory named Windriver 2009 when I installed the new Windriver for this year. I wouldn't have expected it to add sample projects across directories like that. I know my project is up to date, but I will check it out tomorrow. I had a problem with my updater not installing correctly and had to move the files from it by hand after extracting the data manually, is it possible that a correctly running updater deletes projects that are installed by Windriver by default and since all I did was add due to installer error that it left the IterativeRobot Demo I was using?

I would like to thank everyone for all their help. Tonight was a good night, one that we needed as we were getting quite distressed.

[MamaSpoldi]

jhersh, We are getting this same relocation error, but only when the code has been deployed; we are able to debug the code without an apparent issues. Does this make any sense to you? Is there more than one place where this needs to be set (ie. are there separate settings used for the build or dynamic linking when it is debugged vs. when it is downloaded)?

[jhersh]

Originally Posted by MamaSpoldi

jhersh, We are getting this same relocation error, but only when the code has been deployed; we are able to debug the code without an apparent issues. Does this make any sense to you? Is there more than one place where this needs to be set (ie. are there separate settings used for the build or dynamic linking when it is debugged vs. when it is downloaded)?

Are you maybe deploying the NonDebug version of your application?

[MamaSpoldi]

I believe that we are deploying the debug version of the code... the path to the .out file is in the debug subdirectory under the project directory.

Is it likely that the dynamic linking is handled differently on the cRIO during debug vs. when the code is deployed?

Regardless, I plan to try this build option tonight and I will let you know how it works out.

Thanks for your help.

[jhersh]

Originally Posted by MamaSpoldi

I believe that we are deploying the debug version of the code... the path to the .out file is in the debug subdirectory under the project directory.

That would be the same debug build, then.

Originally Posted by MamaSpoldi

Is it likely that the dynamic linking is handled differently on the cRIO during debug vs. when the code is deployed?

Nope... in fact, the deployment happens by simply picking up that file, renaming it to FRC_UserProgram.out and FTPing it to the cRIO. It doesn't even get relinked between the two methods of running.

Chances are you are just getting lucky when it works in debug and happens to align in a 24-bit window. Triple check that the -mlongcall flag is getting used. You should see it in the Build Console on each line (for compiling each file) as an option to "ccppc".

-Joe

[MamaSpoldi]

Thank you for your help... this fix worked!!!

[gvarndell]

Originally Posted by MamaSpoldi

Is it likely that the dynamic linking is handled differently on the cRIO during debug vs. when the code is deployed?

Sorry, I've been ignoring this thread for a while and didn't see this until just now.
The answer is yes.
When your DKM is loaded by the debugger, it will almost certainly be loaded into a different memory region than if it is loaded by the in-kernel facilities.

Edit: of course, if the module is compiled long call, it won't matter. If it's not, you have luck-of-the-draw.