Is it possible at all to write firmware for particles in .net? Specifically in c#? If not, can it be? If not, then particle, can you build us a .net version? Please? I’ll buy some.
1 Like
No. .net framework is a Windows specific thing, that provides the libraries and runtime environment to make programming for Windows easier. There is a cross platform version, called Mono, but again, that’s intended to provide the layer between the user program and the operating system. Embedded devices, such as the particle devices, don’t really have an operating system as such, so there is no need for it.
As to the C# question, in theory, yes it would be possible, but…why? If you know C#, it shouldn’t be too hard to learn C++.
2 Likes
.net is totally pointless on microcontrollers, its specifically for making windows forms programming easier.
Well, that’s not true at all, @sej7278 .Net is designed for, and enables, far more capabilities than just winforms development. And it DOES exist, quite well, on microcontrollers. I don’t believe it needs to have its full framework, but there is a small version of it that lets you run the necessary components of microcontrollers just fine. Case in point: Netduino. I would love to see it on a particle, but I don’t care really if it’s .net or just C#.
@mumblepins Why C#? Because I like it. It has a lot of high level conveniences that C++ doesn’t. I can get around in C++ easy enough, but I miss things like auto-properties and foreach.
1 Like
Please don’t throw out general comments like this, especially when they are not true
https://dev.windows.com/en-us/iot
@mumblepins, it may have started off as Windows specific, but it is growing out of that confined space - or at least attempts to - despite being an MS product.
But AFAIK they have even gone fully open source with the framework and encourage every one (even Apple ;-)) to contribute.
And I do know C++ (way before C# came round) but still enjoy the convenience of C# 
I too would like to see some .NET support on 
Particle devices.
well ok, microsoft are pretty new to iot stuff, and we already have a working c++ solution.
i’m sure particle would look at pull requests though if you want to reinvent the wheel.
Sure, but it's not about reinventing the wheel.
Why do others try to get Python/MicroPython/Viper or anything else to run on Particles?
Or where would we be nowadays if machine code (e.g. ASM) programmers told us (with a smirk 
) back then
1 Like
i’d rather you not misquote me @ScruffR but i’m not prepared to argue anymore, i certainly wouldn’t be averse to an arm assembler implementation though.
1 Like
Well, I’ll admit, I didn’t know about netduino until now. It shouldn’t be too hard to port, if people want to do it, considering they are already running on the Cortex-M3 (like Particle). Personally, though, if it’s going to happen, I think it should be a community lead effort, as I feel like the Particle team has it’s hands full enough with the standard wiring implementation 
.
Me too!
Tthe LIKE was not for the other part of that post, tho'
So netduino runs on hardware similar to particles already? I wonder if it would be easy to flash their firmware to the particles, then, and make it work. I realize some extra work would need done to make the wifi stuff and spark API available.
I looked into it briefly actually (curiosity killed the cat…), and Netduino is annoying with their source, aka the most recent builds of the SDK aren’t aligned with their most recent source, and they don’t seem to have it available on a nice source control platform (such as github) 
. </rant> On the plus side, it all appears to be Apache 2 license, so no problems there.
Anyways, if you’re willing to dig through the code, yeah, I don’t think it would be too hard. The Netduino 2 actually uses the same µC as the Photon, the STM32F205, though actually one with less flash (768 kb compared to 1 MB). I’m not willing to try flashing it though without a JTAG interface, as I don’t feel like bricking my toys
1 Like
Hmm. I wonder if I have such an interface…would one of those be used for flashing https://www.sparkfun.com/products/11113?
Apparently not…but I believe https://www.sparkfun.com/products/8278 would work. I may invest in one when I have some time and try to get particlenet.io going 
The programmer shield would probably be optimal, if not quite out yet. Formerly, the JTAG shield. As this says “Careful! Low level dragons here!”
Here I am again, resurrecting a very old topic. I feel that creating a second topic is worse than resurrecting an old one.
I just wanted to chime in here saying that support for the .NET Micro Framework would be a wonderful addition. I do not expect this to ever occur, I’ll add. C++ is not a great language. Arguably, it is not even a “good” language. One can do things they want to do much more easily in C#, with just as much flexibility, and without the majority of the snags that novice C++ developers will encounter when working in the embedded realm.
I’ve purchased 4 asset tracker kits, 2 of v1 and 2 of v2, and I am still struggling with accuracy. On one of them, the inductor right next to the “Mode” button spontaneously popped and now the $69 device simply doesn’t work.
Last night I got the exact same functionality out of a $100 Windows Phone and C# in about 45 minutes, and it is reliably demonstrating greater accuracy, somehow. I’ve ordered an $18 Pelican case, and with those two purchases I have exactly what the Asset Tracker gives you, minus the Particle Cloud, which is a good thing in my case, since I am trying to send my data to AWS IoT, and currently, Particle devices don’t support this on the public Particle cloud.
So, I’m winning very easily with .NET. Granted, this is not the .NET Micro Framework, and that’s only because it isn’t available on phones, either. There are some things that I am losing, and that I will very much miss, such as the fleet management. That stuff is awesome and I will have to implement my own with the help of my employer’s Windows admin teams.
I’m not at all saying that this is a route that everyone should take. It makes sense for my particular use case, and it has yet to be tested at scale.
I can say, though, I got the same functionality out of C# in 45 minutes that I could get out of a C++ process running on FreeRTOS in a much, much longer timeframe. Probably two orders of magnitude more time spent on C++ for the same result. It is very hard for me to pay attention to people who say “learning C++ isn’t that hard” after this experience, and a large reason for that is that it isn’t simply C++ that one needs to learn. One needs to learn C++, Particle devices, FreeRTOS, and multi-threaded embedded application development, and each of those are non-trivial.
For people familiar with .NET, Particle is a very tough sell, despite all of its clear and obvious strengths. So don’t just dismiss .NET out of hand.
Some interesting points you raise here, thank you for taking the time to write them down. We are always looking to help make application developers like yourself more productive.
Would you mind sharing the C++ code you wrote and the working C# application code?
C++ code that runs on my Particle devices is here: https://gist.github.com/naikrovek/330fb772c3c00fb34ef60bea73d120ee
I suspect that the differences I am seeing in GPS accuracy are not due to the code, but the hardware design. The V2 asset trackers reliably give better (more true to real world) results than the V1, and the only difference in those in my application is the hardware.
The C# code boils down to the first block of sample code on this page: https://docs.microsoft.com/en-us/uwp/api/windows.devices.geolocation.geolocator
Note that this IS NOT the .net Micro Framework. This is UWP, which is a whole other beast. My point is that even though the particle devices and cloud are legitimately excellent, I was able to get what I wanted for slightly less money and significantly less time by using .net, and to not dismiss .net out of hand, which I saw early in this very old thread.
Thanks.
Very interesting writeup, and clever idea using a $100 windows phone.
I have about a million opinions on all this, but I’ll summarize:
- “it shouldn’t be too hard to learn C++” I’d say that’s rarely true, even in this context.
- “.net is […] specifically for making windows forms programming easier.” - false
- People like RUST, and C# in theory could be like that. And it would flat out destroy JavaScript and Python.
- Bringing .NET framework along judiciously would be very good as well
Plus, a rant: Always bugs me you can spend $75 on a budget phone whose hardware blows the doors off of the gear we get all excited about.
The economies of large scale hardware production are really neat. For $50, or $100, you can get a platform with a battery, tons of sensors, cameras, a high-resolution display with multi-touch, microphone, speaker(s), cellular modem, Wi-Fi, Bluetooth, and all the necessary hardware to take care of all those peripherals. 
You also get zero support from the hardware vendor, unless you buy a very large quantity of devices. 
Phones have their own set of strengths, and their own set of drawbacks.
1 Like