NI Linux Real-Time Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting Mono running on your target (pre-2017)

These steps apply to OS releases prior to 2017 (in 2017 onward, mono support exists in the NI feeds)

 

To get C# goodness running on your target, there's now a dev/mono_support branch on NI's github nilrt repo, https://github.com/ni/nilrt.git .

 

Here, I'll run through some of the steps that you can use to get mono running on your target. These steps are a bit rough, but should get you started.

 

These MUST be run on a Linux machine with build-y type tools installed (GCC, make, bison, etc.)

 

//Get the repository downloaded

git clone https://github.com/ni/nilrt.git

// Move to the repo

cd nilrt

// Check out the branch that adds mono

git checkout dev/mono_support

// Read the README. For real. Do it.

// Run the helper script to download additional source.

./nibb.sh update

// Run the helper script to configure the build system for your

// target. Answer the prompts

./nibb.sh config

// Set the environment to use the settings you just configured,

// replace $MACHINE with the target you picked

source env-nilrt-$MACHINE

// Build mono! Now, note, this step may break due to one of a

// few reasons, be it download sources being down, tools missing

// from your system, etc. Fix (or post about it) and rebuild

bitbake mono

 

When the build finishes successfully, you'll have some packages that you can copy to your target and install. Here is a point of some annoyance since there are depenedencies that may not be on the NI feed server that are required by mono's ipk. But you just built everything that is needed to install, so it's just a matter of copying over the needed ipk files to the target and installing them manually.

 

Basically, use the following flow, starting with PACKAGE = mono:

  1. Copy PACKAGE ipk file to the target
  2. Attempt to install the ipk file through opkg
    • If it didn't work, it probably complained about some dependencies missing. PACKAGE = first dependency
    • If it did, PACKAGE = the parent who would not install due to the current PACKAGE missing
  3. Repeat (go to 1 with this new PACKAGE) until mono installs

If you wanted to be really fancy, you could setup a webserver on your build machine (or use an existing webserver you have access to) and run bitbake package-index to create a web-hostable feed, modify your target to include this new feed, and directly install from your target (opkg update && opkg install mono, the new feed will have all of the dependencies needed as you used that build to make monon in the first place)

Comments
tduffy
Member
Member
on

Hi Brad,

WIth the angstrom repository (pre 14.x), installing mono was as simple as 'opkg install mono'.  Any insight into why this didn't make it over into the NI package repo?  And what is the time-line to expect it to be added?

Thanks,

-TD

BradM
Active Participant
Active Participant
on

The primary reason was that, in the past, targets were pre-configured to point to angstrom repos. These repos contained a lot of packages that were of interest to many use-cases, so mono was available.

With NI-provided repositories, we have the benefit of having control over the repository along with the guaranteed uptime of ni.com, but we don't have nearly the same selection of packages available since most are "uninteresting" to what NI thinks customers want. Asking for something helps us see what customers actually want.

I'm not 100% sure on the timeline, but I can tell you that you're not the first who is interested in mono/C#.

tduffy
Member
Member
on

Thanks for the quick reply Brad!

Who do I need to contact to

  1. Inform them that we are 100% interested in mono, and would prefer not to have to build it each time.
  2. Confirm a commitment date for mono being added to the NI repo?

Thanks again.

-TD

BradM
Active Participant
Active Participant
on

tduffy wrote:


                       

Thanks for the quick reply Brad!

Who do I need to contact to

  1. Inform them that we are 100% interested in mono, and would prefer not to have to build it each time.
  2. Confirm a commitment date for mono being added to the NI repo?

Thanks again.

-TD


                   

Your interest has been communicated to the right people.

In the meanwhile, you could try adding some of the older repos to your /etc/opkg/ folder to pull in other feeds, however the most recent one that I could track down for this architecture is 2012:

http://feeds.angstrom-distribution.org/feeds/v2012.12/ipk/eglibc/armv7a-vfp-neon/ (note that you'd add one feed .conf for each folder you're interested in). I see that they do indeed include mono packages, but I have not tested them.

thad.house
Member
Member
on

Now the the FRC competition season is over, I'm going to try and get Mono working on the RoboRIO.

I tried to build this a few weeks ago, but it kept failing. I didn't have much time to debug this, but has anybody actually been able to successfully compile this? If so, does anybody have the precompiled binary so I don't have to set up a linux machine again?

Also, I tried the build from the 2012 repo. It successfully deployed, and I was able to run c# code, but anytime I tried to interop between a HAL and c# it would segfault. I'm guessing thats from using a 3 year old version of mono, so I hope a new build works better.

BradM
Active Participant
Active Participant
on

thad.house wrote:

...

I tried to build this a few weeks ago, but it kept failing. I didn't have much time to debug this, but has anybody actually been able to successfully compile this?

...

Obviously, I tested this out before pushing the branch. I have noted that attempting to build with gcc 4.9+ on your base system will fail. Do you happen to have the system still up?

In any case, for disambiguation, are you talking about hal, hal, or some other hal?

thad.house
Member
Member
on

I still have the system set up, and tried again last night. It was a VM built using Ubuntu 14.10, with GCC 4.9. After lots of googling, it seemed like that was the issue, So I'm going to try building it with an older version of Ubuntu that uses older GCC. Any recomendations on a build distrobution?

Also i'm trying to interface with the FRC Hardware Abstraction Layer. I was able to communicate with the FPGA, but passing void pointers back and forth was failing, so I hope a newer version of mono helps with that.

BradM
Active Participant
Active Participant
on

I currently use Arch Linux (which is a rolling distribution that tends on the bleeding-edge), so for my OE building needs I created a Debian Wheezy chroot using debootstrap.

Mapping that to 'buntu, it seems like we're looking at Oneiric-to-Saucy (http://askubuntu.com/questions/445487/which-ubuntu-version-is-equivalent-to-debian-squeeze)

thad.house
Member
Member
on

Downgrading to 13.04 worked, and I was able to successfully get this built. Unfortunately, it did not fix the issue, and I still get segfaults trying to pass around the void pointers. So now I guess I get to learn how to use GDB to debug, and try and figure out what the issue is.

BradM
Active Participant
Active Participant
on

I'm sure you are looking at this resource (among others), but just in case you hadn't seen it: http://www.mono-project.com/docs/debug+profile/debug/

rpietruc
Member
Member
on

I successfuly build the nilrt dev/mono_support on current ArchLinux, with following configuration:

BradM
Active Participant
Active Participant
on

rpietruc,

Thanks for the info. I personally would rather not adjust my OS to build something for OE, therefore I'm inclined to use chroot OSs for that, but I know that info will help others.

rpietruc
Member
Member
on

Thanks BradM,

As a better solution than adjusting the OS I added two Dockerfile's to build mono packages based on debian:wheezy Docker container:

https://decibel.ni.com/content/docs/DOC-46934

https://decibel.ni.com/content/docs/DOC-46935

BradM
Active Participant
Active Participant
on

Yeah, that works just as well. That, and it's the new hotness, so good on ya! Thanks for sharing with the community.

aa82
Member
Member
on

@bradm Is this still the most up to date way to install Mono on NI Linux Real-Time?


I would like to install F# on my cRIO-9038. Instructions for Linux are found here (http://fsharp.org/use/linux/), but those require common setups. It would be great if I could simply run

opkg update
opkg install mono-complete
opkg install fsharp

Please add my vote to @tduffy's vote for adding both Mono and F# to the NI package repository. I am migrating away from LabVIEW but still hoping to stick with NI hardware, using LabVIEW as a hardware only language, e.g., using it to only program the FPGA and do other hardware interface tasks. My plan is to move to C# and F# for both Windows and Linux development. The more difficult NI makes it to easily use other development platforms, the easier it will be to move away from NI hardware as well.

BradM
Active Participant
Active Participant
on

@bradm Is this still the most up to date way to install Mono on NI Linux Real-Time?


It is, although the branch on github is still based off of 2015 or 2016 versions of the underlying OpenEmbedded sources. I see that the layer used for getting mono (and the F# package "fsharp") has updated branches that match the versions of the software stack used for more recent NI Linux RT releases.

WallyFromDilbert
Member
Member
on

@Bradm,

Now that .NET Core is starting to become more mature with version 3.0 coming in Q1 2019, could you provide info on if NI is considering supporting or build a opkg package for .NET Core for cRIO?

If so any road map or has this idea been addressed and rejected?

We are looking at replacing part of our LV code with C# and wanted to gather some info.


thanks!

Contributors