Not sure if someone already posted a link here to this article, but I thought it would be of interest to some members on this forum :
http://j.tlns.be/2015/02/getting-started-with-the-raspberry-pi-2-for-net-developers/
9 Likes
Nice tutorial…
Whats the best way to access hardware from that point? Gpio/PWM specifically?
Looks like a blog worth following.
I’ve got a Pi kicking around here somewhere. This might be the time to dust it off and have a play.
I’m a huge fan of the RPi of course, but also find .Net to be the perfect development accelerant, so I have been using the two together for some time. I currently have nine RPi/RPi2 devices live and working as control points, sensor/actuator hubs, and gateways for Molecule.Net. Some are headless, some have Adafruit touch displays and a couple are driving TV set-top interfaces based on xbmc.
One of the things you immediately come up against is the problem of managing these devices and deploying updates to them without having to physically touch them, and for me the perfect solution (pending Win10 wonders) has been resin.io. [I don’t have any connection to resin.io - I’m just another user]
With resin.io, you can use .Net together with docker to deploy .Net/Mono code to tens, hundreds or thousands of RPi or Beaglebone devices. And, of course, because it is .Net, you can abstract away a LOT of hardware and platform differences.
I have my resin.io experiences posted here : http://myinternetthings.blogspot.com/
This is a relatively new blog though I will be expanding it regularly. I have currently paused to dive into Molecule.Net to get some close-to-the-metal comms work done there first so that I can deploy a bunch of smaller scale sensor/actuator devices too.
5 Likes
There are a few .Net GPIO assemblies out there, including one partial attempt to port the NETMF gpio stack (I haven’t played with that one). Most of the various GPIO assys out there use PInvoke to link to the native DLL for RPi GPIO although you can manage GPIO (slowly) through the filesystem too.
One problem you face though (and one not well covered by the existing libs) is that there isn’t just one RPi - there are a half dozen or so models that are electrically distinct (pins moved, capabilities changed, etc). So, what is needed is a single GPIO abstraction to rule them all while also providing board capability information in a .Net namespace.
I took the approach of extending the Cpu class to provide more capability information about the RPi and then ported Cpu.Pin and related functionality in a way that should work across all RPi (and Beaglebone) boards.
I shelved that work last month because I wanted to wait to see what the Microsoft IoT approach to GPIO was going to be so that I could decide whether I was extending the correct model or not.
Now, I work for Microsoft (in a non-IoT area), so of course I am eager to try out Win10 on RPi, but I also need resin.io-style deployement/management functionality so sometime in May I am going to have to decide whether to continue this work or ditch it and run my RPis on Win10 and that will depend on whether finishing GPIO or wiring up resin.io-like management is going to be less work.
If I do bring this to completion, I’ll mention it here. My current queue is BLE/wifi for Molecule.net and then a return to this work.
2 Likes
@ mcalsyn - Thanks for sharing this info. I have not heard of resin.io before now and I’m going to enjoy learning more about it. Is it purely for .NET or can you deploy any binaries using that? (I guess I should first read up myself before asking silly questions like that)
So far I’ve been using C++ through Visual Studion and Visual GDB to develop on Raspberry Pi. The thing that I like about using pure C++ is that I can use so much of existing code that I already have for other platform. But I am definetely curios to see how .NET Mono apps work. Can you also use line by line debugging while developing in .NET on the RPi?
1 Like
Pretty much anything you can do on an RPi, you can deploy with resin.io
Yup.
I use .Net for exactly the same reasons you mention for choosing C/C++. I do have more experience in C/C++, but I find that the platform abstractions between Linux and Windows, and between motes, mobiles, desktop and cloud are more consistent in the managed languages than in C/C++. Yes, you are working closer to the metal with unmanaged languages, but you often can’t find the same reusable components or the same consistency in representations. Consider filesystem and networking abstractions - they are far more available and consistent in the managed languages than C/C++ (in my experience).
1 Like
@ mcalsyn Wow, I am excited to read about your adventures in rpi and the .net world. I to am anxiously waiting on win10iot to get started with .net and pi.
Please keep us posted ASAP on your progress. I guess we have to wait until build to get the bits a?
Terrence
You could always use c++.net (c++/cli) and have the worst of both worlds!
(seriously, does anyone ever use c++.net?)
Yeah, but in my case only as glue between native and managed code (e.g., OpenGL based views in a Win8 app). It’s not the most enjoyable experience, but great to have the option when you need it.
Yup - looks that way. I am sure there are internal builds available, but I haven’t had time to look at them. So much to do - so little time. I am planning on setting aside time to do a deep dive into it after the Build presentations come out. I’m especially interested in whether/how they are going to approach presenting a consistent managed GPIO api across NETMF and Win10, since that (to me) is pretty core to cross-platform code reuse.
Anyway, rather than trying to figure it out by digging into internal resources (which I couldn’t talk about here anyway), I am going to wait like everyone else for the much better organized Build presentations and then fire up an RPi2 with a Win10 image to give it a test drive.