Find content
Male
Try upgrading to the latest firmware, and you should be good to go.
Hi Chris
What did you change?
Best regards
Cuno
Posts I've Made
In Topic: Introducing Llilum, the native-compiled (NETMF) proof of concept
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
