Netduino home hardware projects downloads community

Jump to content


Photo

Introducing Llilum, the native-compiled (NETMF) proof of concept


  • Please log in to reply
26 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 08 July 2015 - 10:42 PM

Netduino 3 and Netduino.IP were designed from the ground-up to work great with the upcoming NETMF 4.4 (MSIL interpreter)--but they were also designed to excel with a native-compiled NETMF.

The NETMF interpreter is really great for a lot of applications, but there are some applications where a native-compiled runtime for Cortex-M devices would be really awesome. Think "up to 300 times faster" awesome.

Today Microsoft has published a sneak peek into Llilum (pronounced "LIL-EEE-UM"), an AOT-compiled "NETMF" proof of concept for Cortex-M devices.

Here are some links to explore:

Llilum dev overview
Llilum system description
Very early performance data

This project includes quite a bit of tech that Microsoft has already built--as well as an integration of the NETMF stack, LLVM compilation and more.

There is a lot to digest in the tech overview...so here's a quick simplification in my own words:

Summary Description
"[The llilum proof of concept] is a future native-compiled option for .NET Micro Framework applications. For Cortex-M class micros. Up to 300 times faster for some operations like GPIO bitbanging. Additional C# language features. Code share-ability with Windows IoT UWP apps (think of the UWP APIs from NETMF 4.4). And all the hardware benefits of inexpensive, power-saving Cortex-M micros."

This is all still technically proof of concept, but that said...lots of great stuff to come. Kudos to the NETMF team (and all others who have been involved on this) for all the great work.

Chris

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 08 July 2015 - 10:56 PM

And just to set good expectations...please note the words "proof of concept".

The combination of NETMF (C# to IL) + Zelig (IL to ARMv4/v5) + LLVM (ARMv4/v5 to ARMv7) + Netduino.IP with Cortex-M is really, really mouthwatering.

But for now...still just a proof of concept. Let's all give the NETMF team lots of love and encouragement on this direction. And once this gets a bit further along perhaps we can all push our Netduino gear to do all sorts of cool new tricks. :)

Chris

P.S. There are tradeoffs between IL interpreters, JIT, and AOT. If and when this proof of concept becomes a production release, both the NETMF Interpreter and Llilum will have applications where they excel over the other. The key here is that the two options combined effectively make .NET the perfect solution for the majority of IoT projects. Super cool.

#3 dankline

dankline

    New Member

  • Members
  • Pip
  • 6 posts

Posted 09 July 2015 - 12:55 AM

Hi Chris,

 

Please keep me on the front edge of this.  I am presenting "Are You an Explorer?  IoT and Blazing you own trail." at That Conference 2015.  Unfortunately, though covered in the materials of options and comparisons, Netduino is poorly represented for the OpenSpaces hands on sessions.  I have a few of my own devices that I will be bringing.

 

I definitely need to have current information on the progress with Lilium.  If released by That Conference, I'd love to have one to demo.

 

Thanks,

 

Dan Kline



#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 July 2015 - 01:13 AM

Hey Dan,

Please keep me on the front edge of this.  I am presenting "Are You an Explorer?  IoT and Blazing you own trail." at That Conference 2015.

Dang, I wish I could come camping with you guys. That sounds pretty fun.

Llilum is still proof of concept and probably won't be ready for major demos by next month, but stay tuned longer-term. It's pretty cool technology.

P.S. Thanks a bunch for bringing your Netduinos to the campout... Super cool.

Chris

#5 Paolo Patierno

Paolo Patierno

    Advanced Member

  • Members
  • PipPipPip
  • 169 posts
  • LocationItaly

Posted 09 July 2015 - 04:47 AM

Chris this is a great new ... net mf can be definitely a platform for competing with other native.
You talk about gpio bit banging and it's ok as we can see from performance but what about the real time feature strictly related to determinism and interrupts system ?

Paolo

Paolo Patierno

Microsoft MVP on Windows Embedded & IoT

Azure Advisor

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience

Blog : Embedded101
?


#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 July 2015 - 04:55 AM

Hey Paolo,

Chris this is a great new ... net mf can be definitely a platform for competing with other native.

Not just competing... Superior in oh so many ways :)

You talk about gpio bit banging and it's ok as we can see from performance but what about the real time feature strictly related to determinism and interrupts system ?


Llilum isn't currently spec'd to be a deterministic interrupt system. You could potentially run it inside CMSIS RTOS and put deterministic code there...or otherwise use native code directly from interrupts. Sometime in the future there could even potentially be an option for mixed native and managed-compiled-to-native code in a single project, although that's probably way too much to ask for a first version.

Chris

#7 Paolo Patierno

Paolo Patierno

    Advanced Member

  • Members
  • PipPipPip
  • 169 posts
  • LocationItaly

Posted 09 July 2015 - 05:10 AM

However bit banging and high frequency gpio are good but the best could be to have a real time and deterministic system (on the interrupts side) that you can program in managed code as C# but with performance of a system developed in C

:-)

Paolo Patierno

Microsoft MVP on Windows Embedded & IoT

Azure Advisor

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience

Blog : Embedded101
?


#8 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZrich / Switzerland

Posted 09 July 2015 - 09:11 AM

This project includes quite a bit of tech that Microsoft has already built--as well as an integration of the NETMF stack

In which way is the NETMF stack integrated? As far as I have seen, Llilum is a completely separate technology stack, no NETMF code involved anywhere.



#9 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZrich / Switzerland

Posted 09 July 2015 - 09:14 AM

However bit banging and high frequency gpio are good but the best could be to have a real time and deterministic system (on the interrupts side) that you can program in managed code as C# but with performance of a system developed in C

:-)

Yes, I would love to create such a system :-) Done it many years ago for Java. But unfortunately, no budget ;-)



#10 gismo

gismo

    Advanced Member

  • Members
  • PipPipPip
  • 110 posts

Posted 09 July 2015 - 03:03 PM

So, does this mean we would have access to input capture and direct access to counters/timers on the chip?



#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 July 2015 - 04:08 PM

Hey Paolo,

However bit banging and high frequency gpio are good but the best could be to have a real time and deterministic system (on the interrupts side) that you can program in managed code as C# but with performance of a system developed in C

With a native-compiled proof of concept like Llilum, you still have real-world issues like garbage collectors to deal with. There is a possibility that a GC-less application could be built, and there is a possibility that a GC which honors determinism around interrupts is possible. But to be clear none of these are announced features--or necessarily on the roadmap. It's all very early still, and we're just super-excited for the new bits.

Chris

#12 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 July 2015 - 04:13 PM

Hey Cuno,

In which way is the NETMF stack integrated? As far as I have seen, Llilum is a completely separate technology stack, no NETMF code involved anywhere.

Llilum is still proof of concept, but the plan is to integrate the NETMF stack into the Llilum toolchain. Here's a quick note about this from Lorenzo's post on the NETMF blog.

We will grow this project side by side with .NET Micro Framework 4.4 and eventually integrate the .NET MF stack into the LLILUM tool chain to achieve both a smaller code size and higher execution speed.


Please note that this doesn't mean that the NETMF runtime will be imported as-is. The goals here will likely include code reuse. Again...this is all very early and still proof of concept...but lots more to come (including exception handling in a future release).

Chris

#13 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 July 2015 - 04:14 PM

Hi gismo,

So, does this mean we would have access to input capture and direct access to counters/timers on the chip?

Potentially. There is a lot that could be done, but a project like this also needs to set realistic goals on what can ship in v1, what makes the cut-list for vNext, etc. This is certainly something that would be _very_ interesting though, with a native-compiled .NET platform for Cortex-M devices.

Chris

#14 gismo

gismo

    Advanced Member

  • Members
  • PipPipPip
  • 110 posts

Posted 09 July 2015 - 04:16 PM

I'll keep my fingers crossed, but I won't hold my breath...



#15 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 July 2015 - 04:30 PM

I'll keep my fingers crossed, but I won't hold my breath...

Yes, please...no holding your breath :) Llilum is really really cool but, again, it's a proof of concept right now. It will keep getting better and better, and there are a lot of things to get excited about, but we should get excited about them as they become available.

Chris

#16 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 12 July 2015 - 10:50 AM

Hey Paolo,

With a native-compiled proof of concept like Llilum, you still have real-world issues like garbage collectors to deal with. There is a possibility that a GC-less application could be built, and there is a possibility that a GC which honors determinism around interrupts is possible. But to be clear none of these are announced features--or necessarily on the roadmap. It's all very early still, and we're just super-excited for the new bits.

Chris

 

I think none would need (strictly-speaking) a Real-Time-Netduino, otherwise you'd opt for a different beast, and -yes- maybe programming in some native language.

Instead, I believe the typical req' of the Netduino user is the ability to interface with some I/O: that is, bit-banging, hi-res capture, etc.

 

So, all the Netduino would need is some hacky-ability to plug a native-coded section. Let's say the "Go" idea, but full-software solved.

I remember an user of this forum, who was very smart, and created kinda "hook" so that the regular C#-managed code ran together with machine-language bits of program.

I always thought that was the right direction although his own solution was actually too cumbersome to use.

 

Just think to an Arduino-sketch (better: template) against a bunch of Netduino APIs, and the result should be linked to the main app. Although a static linking would require way less resources, I'd rather look in the dynamic one: paying more, but the benefits are satisfying.

Maybe a tiny-tiny Windows COM interface or so...

 

My two cents...


Biggest fault of Netduino? It runs by electricity.

#17 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZrich / Switzerland

Posted 12 July 2015 - 06:43 PM

Maybe a tiny-tiny Windows COM interface or so...

This would support dynamic loading and also component evolution in a very clean and neat way, with relatively little overhead. But on the other hand, if a static system is accepted, still a lot of overhead can be shifted to build time, thereby allowing to reach much smaller microcontrollers than the one of a Netduino - and this approach would create less confusion regarding the positioning of NETMF versus the IoT version of Windows.

 

A COM-based evolution of NETMF was actually considered for the future of NETMF. But the focus for Llilum is to reach smaller microcontrollers. It should also allow for a high degree of hackability, without the need to combine different languages.



#18 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 13 July 2015 - 04:25 AM

This would support dynamic loading and also component evolution in a very clean and neat way, with relatively little overhead. But on the other hand, if a static system is accepted, still a lot of overhead can be shifted to build time, thereby allowing to reach much smaller microcontrollers than the one of a Netduino - and this approach would create less confusion regarding the positioning of NETMF versus the IoT version of Windows.

 

A COM-based evolution of NETMF was actually considered for the future of NETMF. But the focus for Llilum is to reach smaller microcontrollers. It should also allow for a high degree of hackability, without the need to combine different languages.

 

Of course a static binding would be simpler, but...bah...I don't know pros/cons...maybe it's me having an obsessive eye toward the pluggability.

What do you mean about "less confusion" between NETMF and Win-IoT?

 

Really was considered a COM interface for MF?

 

Finally, I agree on the "high-degree of hackability", but whenever you need some hires capture/reproduce signal, the GC makes all that unreliable. IMHO, it should be designed some "sandboxed" section dedicated to the RT drivers: a very specific extension with RT capabilities.

Whether the code is interpreted or compiled, should not matter: the sandboxed code has to behave always the same.

 

Cheers


Biggest fault of Netduino? It runs by electricity.

#19 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZrich / Switzerland

Posted 13 July 2015 - 11:18 AM

Of course a static binding would be simpler, but...bah...I don't know pros/cons...maybe it's me having an obsessive eye toward the pluggability.

What do you mean about "less confusion" between NETMF and Win-IoT?

 

Really was considered a COM interface for MF?

 

Finally, I agree on the "high-degree of hackability", but whenever you need some hires capture/reproduce signal, the GC makes all that unreliable. IMHO, it should be designed some "sandboxed" section dedicated to the RT drivers: a very specific extension with RT capabilities.

Whether the code is interpreted or compiled, should not matter: the sandboxed code has to behave always the same.

Today, the border between NETMF and the larger .NET implementations is not very clear. Mostly this is a problem of positioning, leading to the question where a given platform stops being a good fit. Maybe we will evolve towards a clearer situation where we have the Raspberry Pi class of microprocessors, with large external memories, dynamic code loading, and Windows IoT on the one hand, and Llilum tools for Cortex-M based systems, with static code and no operating system in the traditional sense.

 

And possibly we will have real-time capabilities, who knows. In our experience, it is often possible to initialize an embedded application which may involve memory allocation and garbage collection, and then start one or several real-time tasks, which do not allocate any memory. Thus the GC does not run after the initialization step. This is e.g. how we implemented our quadrocopter code in C# (https://www.ghielect...id=12602&page=1). Maybe this approach could be supported more systematically, e.g. by giving compile-time errors wherever real-time code might inadvertantly cause memory allocations.

 

But I agree: a sandboxed approach that partitions part of the processor bandwidth statically to real-time code would also be the preferred approach as far as I am concerned. My hope is that Llilum will be hackable enough that we could implement something like this ourselves with relatively little effort. For example, it is one of the goals for Llilum that you could provide your own thread implementation. We'll see.

 

Yes, a COM-based NETMF variant has indeed been considered some time ago.

 

As for your obsession regarding pluggability ^_^ - actually a high degree of pluggability could be provided at build time as well, if the tool chain were prepared for it, e.g. using compile-time reflection and similar concepts. Not sure how much of a design goal this is for Llilum, though. And it's much more complex to correctly design suitable tool chain APIs, compared to supporting the COM memory layout and calling conventions.

 

Best regards

 

Cuno



#20 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZrich / Switzerland

Posted 17 July 2015 - 06:59 AM

 

Llilum is still proof of concept, but the plan is to integrate the NETMF stack into the Llilum toolchain. Here's a quick note about this from Lorenzo's post

 

Ah, this may have been a somewhat misleading statement. It is not clear if there will be any shared code eventually, and what it would be. It's too early to tell. The toolchain (apart from VS) and the runtime are completely separate, and the APIs will probably be substantially different as well, at least for the foreseeable future.

 

Lorenzo made the positioning a bit clearer here:

https://github.com/N...mment-122144288

 

"As llilum gradually comes online, we will see how to integrate llilum into both the netmf ecosystem and the llilc technology."

 

PS

Regarding dynamic loading:

"We do know that we will not support features such as dynamic loading with llilum, and that alone suggests that llilum will never replace .NET MF."






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.