search

hmartiro / project-thesis

xJüs, the hexapodal robot with a passive-backbone to improve behavior over harsh terrain.
4 stars 2 forks source link

Compile ARM library and run test program on Beagleboard #64

Closed hmartiro closed 11 years ago

hmartiro commented 11 years ago

Compiled libEposCmd.so successfully, but building a test program fails at link stage because of undefined references to the CommunicationXLib static library used to build EposCmd. similar to this problem

Time to open a ticket w/ Maxon.

hmartiro commented 11 years ago

Assigned to: Herger, Christian From: Martirosyan, Hayk Category: ES:Controllers.Positioning Control Unit.EPOS2.Programming.Linux Summary: EposCmd shared linux library on 32-bit ARM

Click on the following URL to view Issue: http://support.maxonmotor.com/CAisd/pdmweb.exe?OP=DISPLAY_FORM&HTMPL=home.htmpl&id=417923&role=638697&fac=iss

I'm attempting to establish communication with a CAN network of EPOS2 24/2 controllers using an onboard ARM computer, over USB communication.

I recieved the source code for the ARM library, version 4.8.2.0. It includes CommunicationXLib, SystemXLib, CommonXLib, and EposCmd. I've been working to build libEposCmd.so from this code and establish successful communication with the controllers. If there is a precompiled 32-bit ARM library, I would like to have it, with the newest version possible. Otherwise, I'm running into the following issue when I build the library myself using the included readme as a guide:

One note is that I cannot use the command line directives from the readme to build (eclipse -nosplash ...), because the output is just that there is no project matching that name. However, I am able to import the projects into Eclipse and compile the three libraries SystemXLib, CommonXLib, and CommunicationXLib successfully into .a static libraries.

Once I tried to build EposCmd, I received an error about position independent code and that I should recompile with the -fPIC flag. I recompiled all three static libraries with the -fPIC flag, and then the EposCmd library successfully compiled.

However, when I try a test program that uses the library to connect with an EPOS2 controller, it is not able to build. I get linker errors about undefined references, mostly to CVirtualDeviceCommunicationModel:

ubuntu@arm:~/eclipse/xJus-epos/Debug$ make all Building target: xJus-epos Invoking: GCC C++ Linker g++ -L/home/ubuntu/epos-arm/Sources/Epos/EposCmd/Debug -L/home/ubuntu/epos-arm/Sources/Common/CommunicationXLib/Linux/Debug -L/home/ubuntu/epos-arm/Sources/Common/CommonXLib/Linux/Debug -L/home/ubuntu/epos-arm/Sources/Common/SystemXLib/Linux/Debug -o "xJus-epos" ./src/xJus-epos.o -lSystemXLib -lCommonXLib -lCommunicationXLib -lEposCmd /home/ubuntu/epos-arm/Sources/Epos/EposCmd/Debug/libEposCmd.so: undefined reference to CVirtualDeviceCommunicationModel::AbortCommands(void*, bool)' /home/ubuntu/epos-arm/Sources/Epos/EposCmd/Debug/libEposCmd.so: undefined reference toCVirtualDeviceCommunicationModelBase::VCSGetDefaultProtocolStackSettings(CStdStr, CStdStr, CStdStr, CStdStr, unsigned long, unsigned long, CErrorInfo)' /home/ubuntu/epos-arm/Sources/Epos/EposCmd/Debug/libEposCmd.so: undefined reference to `CErrorHandling::GetErrorDescription(unsigned long, CStdStr_)' ........ (many similar errors) collect2: ld returned 1 exit status make: *\ [xJus-epos] Error 1

In this example, I tried including the static libraries as well as the EposCmd library, even though it shouldn't be necessary. The result is the same if I only include EposCmd.

Note: As guided in the readme, I enabled only #define _MMC_I_USB in MmcDefinitions.h and #define _MMC_HW_EPOS2_RS232 in CommunicationModelDefinitions.h, to reduce the size of the output library.

What could the problem be? I would like either to fix this or receive a precompiled 32-bit ARM library that allows my example program to establish communication.

Thank you.

hmartiro commented 11 years ago

Dear Mr. Martirosyan

First of all I have to notice, that the code you received was intended to run on the windows and Linux platform with x86 as a target arch. Arm isn't supported at the moment in "out-of-the-box" model, but as you see we are sharing the source code for our customers. I cannot guarantee or promise more at the moment.

I received an error about position independent...

You imported, the source code to the Eclipse successfully. As I see the only challenge is to compile properly the CommunicationXLib (CVirtualDeviceCommunicationModel/CErrorHandling classes are the part of this library). Please check again the CommunicationXLib project and compiler settings for ErrorHandling.cpp and VirtualDeviceCommunicationModel.cpp files. For some reason (excluded?), they are not the part of compiled library.

I enabled only #define _MMC_I_USB in MmcDefinitions.h and #define _MMC_HW_EPOS2_RS232 Important notice about _MMC_I_USB - This option makes sense only if you can link EposCmd library with the ARM version of the ftdi library (available on http://www.ftdichip.com/Drivers/D2XX.htm).

or receive a precompiled 32-bit ARM library that allows my example program to establish communication. We have unfortunately no plans at the moment to release the EposCmd Linux library for ARM architecture.

Yours sincerely, Dawid Sienkiewicz

hmartiro commented 11 years ago

Figured out why some functions were missing. I was including the 'common' header files, but the CommunicationXLib also has common source files. Tried copying those over to the main source for the library. Definitely a step in the right direction, but there are compiler errors about missing classes when building the CommunicationXLib. Need to investigate further.

hmartiro commented 11 years ago

Decided to try cross compilation because using Eclipse on the Beagleboard is so slow and technically this is the preferred way to do it. Installed and configured the 32-bit ARM toolchain from angstrom as described here. Then, I loaded up the libraries in Eclipse and set up the ARM toolchain using the guide here.

I was able to duplicate the unresolved includes problem I was having on the Beagleboard, and solve it. The three XLib static libraries compiled successfully. Tried to compile EposCmd, but ftd2xx was missing from the toolchain. Need to include that next.

hmartiro commented 11 years ago

Cross compilation with the angstrom arm toolchain didn't work. Hopped on the #beagle IRC channel on freenode (which is a great resource, for the future) and asked about it. Someone said that I should be using the Ubuntu cross-compile toolchain, which makes sense.

I did sudo apt-get install g++-arm-linux-gnueabihf, which matches the compiler on the Beagleboard (except newer, version 4.7.2 vs 4.6.3). Then, I cross-compiled everything. I was able to get a hello world program compiled on the laptop to work on the Beagleboard. However, an EPOS program compiled with the library still gives 'cannot execute binary file' as if the architecture is wrong.

hmartiro commented 11 years ago

Reopened issue asking for newest source code

Thanks for the help. I have fixed the previous error and am able to cross-compile libEposCmd.so using the g++-arm-linux-gnueabihf compiler package in Ubuntu 12.04. I still have problems running it, but I understand that you don't support any specific hardware platform.

However, the source code that I was sent was for the 4.8.2.0 version of the library, as stated in the included readme:

Base library version: 4.8.2.0

Directory structure overview:

Sources - EPOS Software source code libEposCmd.so - compiled EPOS2/RS-232 shared library (target: ARM) releaseInfo.txt - maxon motor ag source code management information

This version of the library does not establish successful communication on Linux for us. We earlier reported a bug that was fixed for library version 4.9.1.1. Would it be possible to get the source code for this updated version of library, so that I can attempt to compile it for ARM? We are building a mobile robot with six EPOS2 24/2 controllers, and have no choice but to use an ARM architecture.

Thank you.

hmartiro commented 11 years ago

Reopened the issue with:

Our hardware platform is a BeagleBoard xM Rev C. The system is able to recognize the EPOS2. However, the problem is not quite what you describe. There are currently two issues for us:

Compilation Issue

Using my laptop, I have successfully cross-compiled a 'Hello World' program using Eclipse CDT and g++-arm-linux-gnueabihf. Transferred to the BeagleBoard, this program runs normally.

Using the same compiler settings in Eclipse, I cross-compile the three common libraries and libEposCmd.so, as well as a test program that just calls VCS_OpenDevice. Transferred to the BeagleBoard, this program does not run and instead immediately returns exit code 1, implying an incompatible architecture.

When I run 'file' and 'readelf -h' on the Hello World program and the EPOS test program, the outputs are identical, despite the fact that one executes and the other does not. Basically, I am trying to figure out why one binary is compatible an the other is not, when I am using the same compiler and flags.

I have also tried compiling the EposCmd library directly on the BeagleBoard rather than cross compiling (though it takes a very long time). I get the following error regarding a type specifier, which I don't know how to resolve. This does not happen when cross-compiling:

/source/CommunicationModel/ProtocolStack/Classes/ProtocolStacks/ProtocolStack_MaxonSerialV1.cpp: In member function ‘virtual int CProtocolStack_MaxonSerialV1::InitGatewayToInterface(CStdString)’: ../source/CommunicationModel/ProtocolStack/Classes/ProtocolStacks/ProtocolStack_MaxonSerialV1.cpp:101:37: error: expected type-specifier before ‘CGatewayMaxonSerialV1ToRS232’ ../source/CommunicationModel/ProtocolStack/Classes/ProtocolStacks/ProtocolStackMaxonSerialV1.cpp:101:37: error: cannot convert ‘int’ to ‘CGatewayPStoI_’ in assignment ../source/CommunicationModel/ProtocolStack/Classes/ProtocolStacks/ProtocolStack_MaxonSerialV1.cpp:101:37: error: expected ‘;’ before ‘CGatewayMaxonSerialV1ToRS232’ make: *\ [source/CommunicationModel/ProtocolStack/Classes/ProtocolStacks/ProtocolStack_MaxonSerialV1.o] Error 1

Library Version Issue

You sent the 4.9.1.1 vs 4.9.1.0 bugfix, which enabled IPM mode to work via CAN. However, for us, the 4.9.1.0 library was different than the 4.8.2.0. Using 4.8.2.0, we still cannot establish communication on Linux at all (OpenDevice returns a null device handle). Using 4.9.1.1, we get a valid handle.

I compiled the 4.8.2.0 source code that I have for my Ubuntu laptop (not ARM), and confirmed that the behavior is the same as the precompiled library of the same version, and the device handle is null.

Thus, something must have changed relevant to EPOS2, because 4.8.2 is unusable for us whereas 4.9.1 is usable except for IPM over CAN. 4.9.2 works perfectly except for blank error codes.

If you can't send us the 4.9.1 source, could you check to see what might have changed from 4.8.2? Otherwise, the source code for 4.8.2 is not useful for us because we cannot establish a device handle.

hmartiro commented 11 years ago

Got a couple of suggestions from David:

hmartiro commented 11 years ago

The problem is likely the ftd2xx library. An explanation of the problem is on this question I made on Stack Overflow. I think it is the issue because the sample program that comes with the ftd2xx library works on my laptop and doesn't on the beagle. The bad news is that if there is no compatible version of ftd2xx released then we might be screwed on the Beagle. Need to see what Maxon says.

hmartiro commented 11 years ago

Confirmed further that ftd2xx is probably the issue. Running a simple ftdi test program works on the laptop but not on the beagle. Even more so, running ldd libftd2xx.so on the laptop lists the library dependencies, but does not on the beagle. Need to run strace on the ldd maybe.

However, someone on stackoverflow said that the beagle's arm7 should be backward compatible with the arm5. In addition, the FTDI readme says that it was tested on arm926, which is newer than arm7. Not sure why it's not working.

Possible solutions:

hmartiro commented 11 years ago

Contacted FTDI. The static library in the Android distribution has the same issues.

hmartiro commented 11 years ago

FTDI is not helpful. SO suggests checking this

hmartiro commented 11 years ago

Issue is hard vs soft float library linking, see SO thread. Can try to get soft copies of dependent libraries.

hmartiro commented 11 years ago

Test program compiled after FTDI provided a hard float library.