.Net standard on a ST32F7 microcontroller
.Net standard on a ST32F7 microcontroller
Really cool. Can’t wait to hear more.
Bet it wont be $9.95
maybe it be $99.5
Until we know the details, what would be the biggest advantage of .net 2.0 in your openion?
For me…nothing, but then again I’m simply pleased
based on info from http://blog.wildernesslabs.co/let-the-revolution-begin-introducing-meadow/
Meadow is the world’s first modern IoT development platform for professional developers. It’s a secure, cloud-managed, connected things platform that runs full .NET Standard 2.x applications (via Mono) on a microcontroller .
seems it was like an Raspberry Pi with WiringPI and MONO (and of course couple of libraries)
Getting more developers using .NET to program micro-controllers only opens up a bigger market for everyone.
Totally true. I love C# and VS is from far the best IDE
I’ve done some digging into this. They mention Mono, so they have either ported mono+jit or mono+aot to the stm32 '746. My guess is they ported the simpler JIT case, because they are putting 32Mb on the board. If it was AOT, you could build a much simpler, cheaper board. Porting mono is about 5000 lines of coding, so not extraordinary, but then you have to go and do a platform abstraction/driver layer, which is a task on par with what TinyCLR and nanomf have done with their driver stack.
You ask what the advantage is over netmf interpreter derivatives. Well, at least 10 times the performance (because it will run as assembly, not interpreted IL), and full support for modern C#/Vb including generics.
If it is not interpreted then it will likely not have debugging, my guess. Then this is like lillum, C# to native compiler?
That’s a fair assumption for AOT compilation, but not JIT’d or interpreted code (there is a mono interpreter). JIT doesn’t fit on MCUs and interp doesn’t give you the full speed benefit, so yeah, AOT is what llilum was shooting for and you’re right - you would have to use traditional JTAG/SWD debugging for your .net code in that case.
But let’s talk about debugging. Consider that a $10 Nucleo board plus VisualGDB ($99) gets you full .net and native debugging. Even in a final design, the addition of four to six pads for SWD plus the snap-off debugger from your Nucleo board gets you debugging. So for around $110 in tooling, you have native-level debugging. That’s a pretty tiny investment for a 10x or more speed improvement.
One of the key attractions of netmf/TinyCLR/nano is that you just plug in USB and debug. But that advantage has eroded significantly as the tooling came down from around $1000-$5000 down to $100 today, and went from baffling Keil-type tooling to the simplicity of Visual Studio with VisualGDB, and it’s still just plug-in-and-debug simple.
To me, the barrier of entry for native-level debugging has fallen so far that in comparison to the speed benefits of native code, the equation has changed completely from 15 years ago.
That said, your average TinyCLR user is not going to be running STM32CubeMX to start new projects, so having a debuggable but AOT-compiled netmf derivative is a huge benefit. You get the programming ease of .Net and retain debuggability that is accessible to all developers.
So whether it is AOT compiled, JIT compiled or mono-interp (interpreted), gaining 10x speed and full .Net 2.0 language support while still retaining accessible debugging is HUGE. Does Meadow do that? I don’t know - haven’t seen it. But I know that that goal is well within reach.
I’m looking into CosmOs. This is yet another project that could be ported to arm … but is in early stage for now…
Wow. Small world. I know Chad Howzer (the guy behind CosmOs) from way back in the day. We did a speaking tour together. It’s completely bizarre that this is the first that I have heard of this project, but it has all the same hallmarks as Meadow and llilum - compiling .net down to some sort of mcu-level native code. I need to take a closer look at this, too.
“Cosmos currently only runs on x86 and x64 processors. It has the capability to run on ARM and other processors as well but currently only Intel is supported.”
…from their FAQ. Not sure what their goal is, but currently it’s not MCUs.
Yet more options for .net developers. I want to see C# everywhere, why not
And that is why there is JTAG on all our new products. TinyCLR is a great option, but it is an “option”. If a user want more speed then they can load native nodules on TinyCLR or use a complete different software. Use Fortran if they want!!
But speaking of speed, TinyCLR runs quite fast on UC55 that I haven’t needed to do anything native so far, except for converting 16ppp to 8ppp, which was about 10 lines of native code. … I need to do a video about this
In less than one month , they will start a kickstarter project for their board. I will participate. If it can help to let people know that they can do Iot development with C#, why not.
TinyClr first then Meadow in the C# developer or hobbyist
Happy to see them succeed, but they’ll have to do it without my money. If there’s any chance that CW (Agent watch and Netduino fellow) benefits in any way from any part of the Wilderness venture, then I won’t touch it with a ten foot fiberglass pole, and DEFINITELY not via Kickstarter. Maybe he’s not associated with that company in any way, shape or form, but nobody has given me that unconditional assurance yet, so I’m out.
Do you refer to Chris Walker story ?