NETMF v5 vs Llilum

[josesimoes]

I’ve asked this before, but considering the ongoing discussion on the vNEXT branch (see #491), I thought it made sense to bring it up again.

Will start by saying that I’m not trying to pick a fight with anyone! Just want to bring different perspectives and ideas to the discussion so it can be more broad and better conclusions rise from it.

I think that no one can argue about what is currently written on the v5 branch docs. Seems like a perfect approach and a good plan to follow.
The thing is that all of that won’t get done in a couple of weekends. It will require a serious amount of effort and work hours.

What about Llilum? Isn’t it supposed to be NETMF revised and augmented? NETMF on steroids? Isn’t Llilum right now on a very advanced development stage?
My point is: all this great momentum and rally of efforts that seems to be picking up in the NETMF community shouldn’t it be better invested in Llilum, rather than on a new version of NETMF?

I’m a huge fan of NETMF, make no mistake! But, if Llilum is the next big thing, if we can get all the goodness of coding embedded systems in C#; have code portability and reuse; awesome experience and productivity with Visual Studio along with all the other good stuff that comes along, why not move there?

Despite also being human, I have no problem with this particular change and I’ll gladly move there and leave NETMF in the past.

To wrap this up I leave these questions for thought:

• Is it pouring that amount of effort on v5 the best course of action?
• Does it make sense?
• Aren't we just being stubborn here by not letting NETMF go and we are trying to perpetuate it just… because…?
• Wouldn't it prove better or wise transferring all this energy to Llilum?
• Or is Llilum a different kind of ‘thing’ that has its own place along with NETMF?

Please share your thoughts about this!

@piwi1263
@cw2
@IngenuityMicro
@tpspencer
@ianlee74
@Stabilitronas
@martincalsyn
@TheTechnoGuy
@maiorfi
@ppatierno
@cpfister
@smaillet-ms
@lt72

[Stabilitronas]

Indeed, I'm having exactly the same doubts!..

I would personally vote for shifting focus on Llilum, and mostly for one specific reason: much wider possibilities of what one can accomplish with C#. For example, an MCU has an integrated temperature sensor. I want to use it in my application. What should I do? At the moment, there are two options:

1. If I use vanilla NETMF, I have to recompile the whole firmware, which is, as we all know, not the easiest task in the world. Also, I have to use C++ language.
2. If I use some of GHI products, I can leverage their managed features (very slow and not suitable for some more sophisticated features, like heavily loaded serial ports), or I can use RLP (which is very powerful, but needs a different IDE, has no debugging, and is still a C/C++ stuff).

So, in both cases it's not easy to add capabilities that originally were not added in mainstream images. And, due to huge amount of different MCU capabilities that vendors compete with, I'm sure mainstream FW images will never have all of them implemented.

Now, surely this situation doesn't automatically require Llilum. NETMF could also get some sort of native extension framework, but if one can code his/her drivers using Llilum in Visual Studio and C#, that would certainly make things easier to contribute. Maybe we could even use NuGets for native code development, what a world that would be!..

Concerning stubbornest of not letting NETMF go... Let's take a glance of what has happened in the recent years. NETMF4.4 has been released almost a year ago, and we still have zero adoption. One cannot buy a board running 4.4. One can only get 4.3.1, which is 2.5 years old, and it actually doesn't differ much from 4.3 which is 3.5 years old. Oh, and VS2015 is still not officially supported, and we're about to get VS2017 (or whatever it will be named). We still have to use VS2013 basically. That's where the NETMF world is basically at: a 3.5+ years old environment. Given the advent of other options (like Windows Iot Core), I think this is a serious drawback.

So, NETMF is aging very, very quickly. Pretty much everyone agrees that its codebase is a very complicated one, and since we're going for an almost clean-sheet route anyway, I totally agree with @josesimoes : why not going straight for Llilum?..

[piwi1263]

@Stabilitronas Now first things first, in the assumption that Llilum is at a ready to continue with state, I would second that one too. I miss the possibility to use the MCU to its full extend. Definately for time critical things. Or Llilum or Netmf extension or a good wiki/doc/blog with clear how to. Preferred choice IS Llilum but at the last I checked it, it was IMHO not even ready for alfa tests. Plus I read something of they complete each other and can/will co-exist

Now for the points you address, I have no (at least not much) issues with compiling whole netmf. Plus if you wanna do native stuff in Llilum you're back in c/c++ too.

For RLP, which is nice but, and I consider that a big but, you have to use GHI boards, nothing against GHI, they rock, but is a dependency.

Now for not being able to buy boards with 4.4, well I had multiple of them and they do run 4.4 with all supported Uart, ADC, I2C, SPI, PWM what ever the board provides and I think there will be more comment to back that up.

And if you read the v5-dev branch dox, there is mentioned to go to the new works of building for VS-Next, if I understood it correctly.

@lt72 and @smaillet-ms can you please clear things up a bit for the Llilum side of things and Netmf, so we all in the discussion have a common base and hopefully understanding how the both Llilum and Netmf go forward.

[tpspencer]

I am watching and reading. Very exciting to see so much discussion on the future of embedded c# frameworks. I am very interested in what Steve and Lorenzo say about the differences in vNext and Llilum, and why there is a push for vNext instead of all efforts going to Llilum. I don't have an opinion yet until we hear more.

[Stabilitronas]

@piwi1263 So where did you buy those 4.4 boards exactly?

[piwi1263]

@Stabilitronas Ask @IngenuityMicro and those boards were even bought last year and since around Q4/2015 on 4.4

[Stabilitronas]

@piwi1263 No no, you misunderstood me. Can you give me a link where I could buy a NETMF 4.4 online? I thought there are none, but maybe I miss something...

[piwi1263]

@Stabilitronas You still have to talk with @IngenuityMicro or do you expect a link to corporate board with 10K employees ?

@Stabilitronas : we also provide a NETMF board that supports 4.3.1 or 4.4. ( https://mikrobusnet.org/project/quail-mainboard )
But the fact that VS2015 has issues with NETMF does not help in promoting 4.4 :(

And I agree with all that @josesimoes and @piwi1263 have written ;)

[Stabilitronas]

@Becafuel Oooh nice, so it's not zero adoption after all!

[smaillet-ms]

@Stabilitronas Can you clarify what you mean when you say VS2015 isn't officially supported? As we released the 4.3 QFE2 to support VS2015 and V4.4 has supported VS2015 from the very beginning. VS "15" will also come along once that's officially released. The work done in 4.3 QFE2 split the VS integration from the SDK so that we could more easily add support for newer versions of VS as they come out without forcing upgrades and allow side by side installation. So I'm confused that someone would claim that VS2015 isn't officially supported.

[Stabilitronas]

@smaillet-ms I'm sorry, my bad. I was unaware that Quail actually officially runs 4.4, so technically, yes, I can buy a 4.4 board and use VS2015 with it (although I don't know if they actually ship 4.4, not 4.3.1. Their download site lists it as "beta"). That being said, GHI is still the major NETMF supplier, and they do not run 4.4 and it doesn't look they will anytime soon. So, VS2015 is out of official support (very clearly stated in https://www.ghielectronics.com/docs/346/using-visual-studio-2015 ) for the absolute majority of the NETMF boards I can buy online, not even talking about the boards that are already bought up until now.

To sum up: GHI and VS2015 — no official support, Microbus and VS2015 — only on beta FW. Anyone else I'm missing?

[smaillet-ms]

One key point on the NETMF v Llilum aspect is that the largest set of changes can (and should) apply to both. The build infrastructure for vNext will be an evolution of the support for Native code projects already in Llilum. The support in Llilum is functional but not ideal, it was built on early work from the VS team for supporting Android and GCC. With the introduction of CLANG with MS CodeGen and other advances in the VS cross platform tooling we can clean that up and make a great story for both platforms. (including native JTAG debug directly in VS!). Furthermore, the PAL work, if designed with unification from the start can serve as a common platform layer for both. (Including a much better and consistent interop story for NETMF)

As to why bother with NETMF at all instead of just going to Llilum... Well that's the community driving that. As pointed out, Llilum is at a functional Alpha state. However, like NETMF isn't a product and relies on volunteer time to take it further. It's a very complex piece of code with a history almost as old as NETMF. Multiple representations of the code are processed, original IL code the internal IR, the generated LLVM IR and ultimately the final output of the LLVM codegen - so getting volunteers up to speed where they can reliably contribute is a tough thing.

Thus, a vNext that can share most of the new effort with Llilum seems like a viable intermediate step. If no-one else believes that to be true it won't happen.

[tpspencer]

@smaillet-ms I like it. Sounds like parallel development (kinda) on both platforms. Thanks for the explanation.

[miloush]

As for VS15, until it gets supported, my VS15 branch should work in VS15-only build environment and generate VS15 SDK/support for MF.

In MF vs LL there are pros&cons for both and it is probably question of what your requirements are and what you are willing to give up for it. Personally, I wouldn't like to abandon any of the two for the other, but neither will have it easy with the amount of resources there seems to be, less so if split.