Linux/MonoDevelop programming SPI/GPIO's

I am looking for a disto/starting point that supports Linux on the BeagleBone black with .NET mono and how I can control the GPIO’s from .NET, preferably from the MonoDevelop IDE.

Is this possible and where can I find, support/ a tutorial on how to install this.

Well Debian has some packages, but I am not sure if every single thing is there to do what you want. There are like 6 runtime packages . . . but, let me just paste the output of apt-cache search . …

root@arm:~# apt-cache search mono | grep runtime
libmono-system-runtime-caching4.0-cil - Mono System.Runtime.Caching Library (for CLI 4.0)
libmono-system-runtime-durableinstancing4.0-cil - Mono System.Runtime.DurableInstancing Library (for CLI 4.0)
libmono-system-runtime-serialization-formatters-soap4.0-cil - Mono System.Runtime.Serialization.Formatters.Soap Library (for CLI 4.0)
libmono-system-runtime-serialization4.0-cil - Mono System.Runtime.Serialization Library (for CLI 4.0)
libmono-system-runtime2.0-cil - Mono System.Runtime Library (for CLI 2.0)
libmono-system-runtime4.0-cil - Mono System.Runtime library (for CLI 4.0)
libmono-microsoft-visualbasic10.0-cil - Visual Basic 2010 runtime libraries for Mono
libmono-microsoft-visualbasic8.0-cil - Visual Basic 2005 runtime libraries for Mono
libopus0 - Opus codec runtime library
python-all - package depending on all supported Python runtime versions
python3-all - package depending on all supported Python 3 runtime versions

This is from Debian wheezy repos on my own beaglebone black. Do us all a favor in the future though, search the groups better as I have answered this question already at least once.

With all that said and out of the way above, you may want to consider a different alternative. I am a fan of .NET myself in terms of RAD tools, and being able to do a lot, but I have been investigating other avenues of approach myself, and finding Mono less, and less attractive. For me, node.js is a better fit, but for you it may not work. Also there is jadonks bonescript that will probably do exactly what you mention above. Anyway, on Windows I think .NET is great, but IMHO does not fit as the best tool for your use case. Even straight C/C++ would be a better fit, and then if you need to display to the outside world, you use something else to do that.

Hey Williams,

how can you access the SPI ports from debian wheezy? IMHO it is only possible with a self-made kernel (with patches from Robert Nelson, etc) or with Ubuntu / Aengstrom and device tree overlay. But i dont know an easy way with (standard) debian. Can you help me?


In Linux and by Linux i mean the general term, everything is a file. So just as a very simple example / explanation UART1 would be /dev/ttyO0 so something like echo “test” > /dev/ttyO0 would put “test” out over UART1. Sorry if i am getting my numbers slightly wrong here, but the gist is the same.

Anyhow it just takes some reading . . .well ok lots of reading to understand some of this, and you’re not alone here either. I myself am learning this newly myself.

"standard" debian ???

The kernel in debian's repo does not currently support this hardware..
All I do with my images is slap a custom kernel on a debian root-file
system. So it's "standard" debian + a custom kernel..


Ok, also do note that I use Robert’s build from source instructions. There is nothing wrong with them at all.

In fact . . .

root@arm:~# uptime
20:48:11 up 12 days, 20:41, 2 users, load average: 0.00, 0.01, 0.05

This BBB is running weechat on freenode #beagle since i booted it up. Also, this BBB is powered via a Windows machine over USB, and would have a much longer uptime if not for that fact. Long story short, we’re solar powered in our home, and I use my laptop USB 3.0 to keep the BBB up when switching over from the genset to solar ( which happens every couple of days when we pump water ).

Everything I have changed on my own, is by following “standard” Debian instructions. Which is to say I have changed a lot. The only differences as I see them is that for netboot, USB boot, etc. That you have to deal with u-boot. Which has nothing to do with Robert’s “custom scripts” per se. The point here is that I can not see it possibly being any more “standard”.