Been watching the MS Build key note and MS just publicly committed to increased investment in .Net MF to improve perf, update to latest Lang features and tools etc.
Stephen.
8 Likes
Steve Teixeira said the same in his “Windows and the Internet of Things” session:
Chickens are not happy
@ Architect - Cool, that one’s in my play list for tonight 
Good news that Microsoft is going to commit more resources to .Net MF. In my option if .Net MF is going to have future the CLR must support the latest language features. One day in the future .Net MF might support parallelisation and the boards have multi cores… Shame Steve did not use a gadgeteer board in his demo, perhaps GHI need to send him one or two.
This means more languages supported, and more feature/performance improvements. I predict that this will lead to more powerful micro controllers like the STM32F4s with more clock, more ram and more flash (also more cost too)
We don’t need more clock or more RAM — we already have it. All we need is a JIT.
1 Like
Not sure about the JIT thing? Can you explain?
Sorry, I meant JIT compiler. It’s th thing that makes managed code execute at native code speed.
Well, a JIT needs some space to where it can compile, therefore it will gobble up RAM for sure.
But since the target platform is well known when deploying, the JIT could be done by VS and only byte code is deployed.
This would have to be done for every platform the program should run on, but at the moment this is not different. And yes, I know that the term JIT means not to precompile, but who cares in this case.
Not sure if debugging would still work then !?
To avoid confusion, we may use AOT (“ahead of time”) compiler rather than JIT.
I don’t care much for a JIT, but I would love to see an AOT compiler - as long as it can work more or less with the exiting HAL drivers. We certainly wouldn’t want to start writing device drivers again from scratch, after we have invested several man years so far in our existing STM32 drivers.
@ Cuno - Yes, AOT was what I meant.
And I really hope that you are not developing “exiting HAL drivers” :naughty:
I would not be surprised that we will see that (AOT) sooner than later. Especially with newly established NET Foundation and MS&Xamarin behind it, Roslyn project and MS promises to put more resources to NETMF.
.NET Native (GitHub - dotnet/coreclr: CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.) could also be an element.
1 Like
@ Cuno - Agree!
Since we have this 32F429IDISCOVERY - Discovery kit with STM32F429ZI MCU * New order code STM32F429I-DISC1 (replaces STM32F429I-DISCO) - STMicroelectronics , RAM is not an issue anymore…
It is for me. For the majority of 32-bit MCUs today, NETMF appears as too much overhead, or is too large to run at all. I’d like to use C# even on an MCU with less than 32 KB of RAM. A JIT would make things worse, not better. An AOT compiler however may well do the trick.
Given the dominance of Cortex-M today, there are relatively few drawbacks to an AOT compiler.
Man, don’t be too greedy 
For the first time hobbyists have a truly cheap access to a MCU with sh*tload of RAM. This is a whole new world. Instead of massaging the program and making compromises one can fully concentrate on the program and the problem that is being solved.
For example, I’m building a demo application with Cerberus, that reads a few sensors, outputs values to N18 display, logs them to SD card and also sends to Thingspeak. And I’m in real trouble with RAM — to the degree that the order I connect modules matters a lot.
Add JIT compiler and NETMF becomes flawless.
Can’t disagree on that, too. Can we have both JIT and AOT compilers?