Linux Cross-Compiler Chain for cRIO-9068

[Tomi_Maila]

One typically uses a cross-compiler to compile linux applications on a PC for embedded hardware platform. What is the preferred linux cross-compiler tool-chain used by NI to build linux application for CRIO-9068? If there's no preconfigured cross-compiler toolchain yet, does anybody know the appropriate configuration for the hardware platform to be used with crosstool-ng? I would prefer not to start guessing the correct parameters?

Tomi Maila

JKI

[Spex]

Hi Tomi,

NI has already built a collection of recommended tools for developing in C/C++ on the cRIO-9068.  The installers are linked from the main beta SW thread in this forum:

https://decibel.ni.com/content/thread/17324?tstart=0

We are still working on providing documentation for how to take your development off the Eclipse/CDT/GCC toolchain, if needed.  The above toolchain is what NI will provide as a free download.

Cheers,

spex

[s.boria]

Regarding the cross toolchain used, could you confirm that it is gcc 4.4.1 for arm eabi (soft fp so not a eabihf version)? I have some issue regarding links to 3rd party libs (such as zlib aso) and a valuable pkgconfig is not so easy to manage on windows. I would prefer to be able to cross compile for arm from a linux (debian) vbox...

Another point is the link to existing libs in the cRIO. It could be usefull to have a tarball of them installed (and perhaps configure) with eclipse package.

Regards,

Seb

[Anna_K.]

Hi Seb,

We are using Mentor Graphics Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux, which is gcc 4.4.1 with soft fp. You have the option to retrieve that same version of the cross compiler for a Linux host from the Mentor site: https://sourcery.mentor.com/GNUToolchain/ .

As for installing cRIO libs in the Eclipse package, we have intentionally made the installer hardware-version agnostic, so we don't currently plan on including libraries for a particular hardwaree target.

Thanks,

Anna

[s.boria]

Hi Anna,

Thanks for your message and the reference to the toolchain (which confirms my assumption based on the gcc -v output)

FYI, I have also tested the emdebian eabi gcc 4.4 toolchain (using -mfloat-abi=softfp) and it seems to work up to now.

Regarding the hf part of my question, I know that performance comparison is often not so easy because it depends on several application factors, but hf computation could provide some great benefits. Nevertheless I will probably ask a question regarding fpu management during NI Week... is it planned to provide an alternative hardfloat BSP using the Zynq FPU (in other words introduce somehow a gcc eabihf as baseline compiler and a compliant kernel) ?

Regards,

Seb

[Sanjay_C.]

Hi Seb,

We don't currently have a plan to offer a hardfloat BSP, but it's something that we're evaluating. We have made some optimizations to math libraries on the system which should alleviate some of the concern over performance.

We're unlikely to provide two BSPs (hf and sf), and will instead look to go one way or another in the long term (either hf or sf) so that we can be much more efficient with making optimizations and updates.

[BradM]

s.boria wrote:

...

FYI, I have also tested the emdebian eabi gcc 4.4 toolchain (using -mfloat-abi=softfp) and it seems to work up to now.

Regarding the hf part of my question, I know that performance comparison is often not so easy because it depends on several application factors, but hf computation could provide some great benefits. Nevertheless I will probably ask a question regarding fpu management during NI Week... is it planned to provide an alternative hardfloat BSP using the Zynq FPU (in other words introduce somehow a gcc eabihf as baseline compiler and a compliant kernel) ?

Regards,

Seb

The benchmarks that tend to show the greatest performance gains are the ones that are specifically tailored to emphasize the differences between the two: ones that contain many floating-point function calls that take many floating-point arguments. Normal applications tend to see marginal improvements.

[metux]

By the way: if anybody looking for precompiled cross-toolchains, go for OSELAS. 

https://public.pengutronix.de/oselas/toolchain/

I wouldn't even waste a single second on vendors like Mentor, who even can't get trivial things like package management right (I recently had to burn a lot of time, just to get their ridiculous installers running automatically).