I have dabbled a bit with Netduino’s and really liked the idea and concept of using C# to program micro-controllers. The problem I see is that once you get past the hello world and basic sensor tinkering projects inevitably I would need to add drivers and modify how the .net micro framework worked in order to provide an acceptable solution to commercial IoT projects.
I have not looked much into the Meadow as of yet but just got an email about the kickstarter closing soon. It looks similar to the Netduino / GHI stuff in that there is code already written to the point where you can get right in and start writing C# and building something.
I steered away from the GHI stuff since they have closed off quite a bit of source code. Works great if their pre-canned modules and code will work but not so great if you need to do something custom or modify how the code works.
Is the Meadow going to be fully open/hackable? I did try out a bit of hacking with the Netduino .NET micro code using the porting guide and other bits of information out there but was quite a chore.
If it is possible to add/modify code to the Realtime OS, Meadow.Core and Meadow.Foundation this would make the project very appealing to me.
Could you give an example? I have been able to write many different applications for .Net MF and have not hit a limitation that was within the realm.
We’ll open up Meadow.Foundation as soon as it stabilizes, as we did with Netduino.Foundation. That’s where all the drivers live, so if you need to add a new driver that’s not already in there, it’s super easy to see how existing drivers are built and extend to additional peripherals. For example, see HIH6130 atmospheric sensor driver.
At least initially, Meadow.Core will be closed source, as it’s a key part of our IP. Can you give me an example of something that you might need to modify there?
Speed, porting and certification.
If I am taking ADC samples and need to run DSP on them quickly and update a screen ASAP there always seems to be an order of magnitude (if not more) in speed slower vs bare metal/RTOS. I know there is always going to be a difference here due to the overhead of running something like Meadow but sometimes we just need tiny slices of time of full control to ensure timing constraints are met.
Porting because everything changes daily. Seems to be common where we try to shoehorn in the slowest device possible and then might need to switch to a different MCU in the same line or in some cases use an entirely different manufacturer. This is due to either speed or peripheral constraints/requirements.
For devices that need to have a CSA safety rating software routines are needed to be added to check memory and operation. Would probably be really hard for Meadow to support redundant MCU cores and all of that but there are some applications where we just needed to ensure the memory was not corrupt and some other checks. This required libraries written in low level code to be added.
What would really make me interested in these high level products is if I could write the non-critical stuff in C# and still have control over the lower level stuff.
All of our products are using C/C++ and have life cycles of 30+ years. When a MCU goes end of life we can salvage quite a bit of code due to the structure. Only the low level code needs to be updated to “glue” the logic back to the bare metal.
If starting with the Meadow board that is all there is. No way to add in or change low level stuff and if there is not enough processing capacity available its back to bare metal / RTOS. When selecting a chip/platform against requirements these high level boards usually are ruled out due to the risk. Nobody wants to choose a board that has a chance of not working causing us to go down the road we would have otherwise.
Bare metal/RTOS/Linux are so universal, hackable and portable that it is hard to justify a closed off solution.
Out of my colleagues I am the most open to adopting hardware like the Netduino/Meadow. I even brought one into work to use for automating testing equipment and testing out new ideas to show off the rapid development. Nobody was interested in investing the time to learn/work with it since the Bare metal/RTOS/Linux is guaranteed to work one way or another. There is also the question what if the Meadow does not make it past a few years? Any other platform we could easily port to another chip but with the Meadow it would be dead in the water.
Makes managers/developers very anxious when starting off with a new product and you know there are definite brick walls that will kill your entire body of work if they are hit.
@tonofsteel thanks for the explanation some quick clarifications that should help:
-
Native Code - We plan on having a native story, where you can write C++ libs and call them in your code. Not in the kickstarter deliverable timeframe, but not too far out, either.
-
Code Escrow - For companies that need insurance if we go out of business, we’ll happily do code escrow, so that even if we go, you’ll have a maintenance story.
I think that should solve most of it. But we’re also thinking hard about managed ways to solve a lot of the performance and RT stuff. Having APIs for real time contracts would solve a lot of things.
Thank you for the information!
This sounds very promising and I look forward to seeing what you come up with.
Is this going to be portable at all? I have not come across any mention of this but from what I can see it looks like it will be locked to a certain STM32F7 device?
Yeah, we plan to bring it to other chips, including the ESP32. And eventually we’ll have a volume licensing model where you can run it on your own circuits at scale.
