I really hope that we don’t have two teams working on the same topic:
Netduino.IP and Microsoft’s improvements in NetMF
I don’t have much experience in how stable the current solution is, but never heard that NetMF’s network is crappy. Is there a reason to be concerned to use the current NetMF for networking?
Also I hope that NetMF will signfifically improve performance. Then this new IP Stack would be very welcome. But until now I cannot see any teams working on JIT or AOT…
@ Alex111 - this has nothing to do with what Microsoft is doing. No double work.
OK - good to know…
Could you give some more insight what Microsoft is improving at the moment?
Thanks, very interesting…
But I am not sure if a RTOS is the best solution.
I would prefer AOT and implement all hardware abstractions directly on C#. Maybe with a very thin layer of C or C++
RTOS doesn’t give you hardware abstraction, and it certainly has nothing to do with AOT compilation. It does give you preemptive multitasking instead of the current system, however. I think it’s a great plan.
I meant if AOT is available, there could be much more low level managed C# code. Maybe even parts of the porting kit could be implemented in C#
IMVHO the current architecture of the .NET Micro Framework simply does not allow support of AOT (native compilation). You’d gain some performance from rewriting or translating managed parts of the framework into native code, but the main bottleneck is the interpreter.
You can imagine the current implementation as one thread with a loop, inside which the runtime interprets CIL instructions and manages [pseudo-] threads and events (plus some other things - GC, debugging etc.).
Now, you take your managed application and compile it into native code (*) - how do you run it in such runtime? You can’t. (**) You need a completely different runtime, i.e. without the interpreter, runtime that has threading, event handling etc. So, what can you do? Actually, a simple thing: you take an RTOS, which already has support for threading, synchronization primitives etc., create one task/thread for your application, second task/thread for GC and you are basically done. Of course, there is some plumbing code that has to be written to interact with the actual hardware, manage memory etc. but it is relatively small; managed library references like corlib will be translated into native code with the application.
If I understand correctly what the Microsoft team is doing, they are changing the architecture so that there is one thread for the existing .NET MF runtime and second thread for the network stack, they provide two implementations: one for Windows and second for Cortex-M using ARM/Keil CMSIS-RTOS RTX. So, the runtime stays the same. However, you should be able to create another task/thread for your native application that would run in parallel with the .NET MF CLR runtime (interpreter) and even interact with the interpreted managed application.
I really like C# and Visual Studio and how awesome it is to write managed applications that run on tiny boards with fancy microcontrollers, but given a task to write anything that needs to meet real-time (***) requirements, I would not use any managed runtime, neither interpreted nor compiled, but an appropriate RTOS + C/C++.
So, in my opinion, AOT for .NET MF is not going to happen, because it would require complete rewrite, there would be nothing left (many RTOS-es come with rich driver libraries). What could Microsoft do is to make .NET Native variant for Cortex-M :whistle:
Hope I did not annoy you too much
(*) There are already many projects and tools that can convert managed code into native, using various ways.
(**) Technically, you could develop/invent some mechanism to overcome or workaround situations that arise when you need to handle threading, events etc. but it will be complicated and almost impossible to troubleshoot.
(***) Real-time is not about speed, it is about deadlines. Real-time operating system - Wikipedia
If it is necessary to change the architecture or even rewrite big parts of the code then it should be started right now until waiting until another technology will jump into this, e.g. javascript, java etc…
There are already projects out there which do really very low level stuff in c# -> COSMOS
Why not write the OS in C#? All C# coders would be future customers for such a system.
Mabye this can be done in steps:
Use a C/C++ RTOS and implement AOT. I can see no reason why compiled C# code cannot run as one or more RTOS tasks? Of course NETMF cannot stay as it is now…
Implement more and more low level stuff in C# until we are at the lowest level. Then a similar technology like in COSMOS could be used to boot into a C# coded OS…
But if it stays like it is now, most of the use case of NETMF is for educational purposes…
Yes, definitely, the runtime needs to be different.
Is there an RTOS whose thread primites are truly a good match for .NET threads? Impedance mismatches in this area tend to be expensive and clumsy.
We are probably talking about a tiny RTOS whose core is less than 10 KB of size (something like FreeRTOS, not something like VxWorks or Windows CE). I would like to see such a tiny RTOS that is a really good match to what a .NET runtime (for compiled .NET code) needs. Modularly scalable from configurations that go from tiny (e.g. no garbage collector, no reflection, in fact almost no runtime system, maybe even single-threaded) to more full-fledged configurations with library components for additional runtime services (dynamic memory management, reflection, real-time task scheduler, cross-debugger support), network stacks, GUI support, etc.
If an existing RTOS allows for this without major kludges, great. Otherwise a new design may be called for. If - and that’s the big if - Microsoft can commit the needed resources to such a project. It would certainly be a major architectural challenge regarding component-based design.
For real-time programming, most RTOS products unfortunately have focused on priority schemes, which I personally find a bad choice for most real-time programming tasks. Real-time is about time constraints: deadlines, periods, etc. Priorities are an artificial construct, have a very indirect relation to time only, and should be avoided like the plague IMHO. PLCs have whacky programming languages and primitive tools, but they got the “time-triggered” part right as far as I’m concerned. Fortunately, as most real-time systems are PLCs.
I think it is worthwhile to try supporting real-time programming at a slightly higher abstraction level than what is common today. That this is feasible and useful, even on slow 68332 MCUs, we have proven over 15 years ago with our bootable Java runtime:
http://java.epicentertech.com/Archive_Embedded/Esmertec%20Jbed/tech-spec-rtos.pdf
If we were able to create the first release of such a system with two engineers working for two years (Beat Heeb for the runtime system including a compiler on the device that compiled Java byte code upon class loading and a garbage collector that did not interfere with the scheduler’s real-time guarantees, and Daniel Diez for the Earliest-Deadline-First scheduler and the driver framework), then Microsoft should be able to achieve something similar as well.
I totally agree with cuno! Current NetMF must be redesigned to be attractive for professional users.
But I fear Microsoft is more focused on cloud based services at the moment…
Even Windows CE (or WEC 2013) seems not to be pushed anymore by Microsoft…, i.e. Microsoft has no interests in embedded (industrial) applications
I’d give up reflection in an instant, no hesitation at all. The GC I’d think about a little longer, but it’s best practice to generate as little collectable garbage as possible anyway, so I would go along in the end. Threads as well are mostly/completely unneeded, especially if we had solid support for the hardware timers available in our devices.
If this would get me native speed, it would be well worth it. Bonus points if it reduced the size of the system such that it could run on even smaller and lower-power devices. Imagine NETMF running on a sub-$1 Cortex-M0 at native speeds. Exciting to think about!
It strikes me that if we removed all this, we may not be as far as we think. A C# frontend to the GCC compiler, building with the ARM backend. A worthy project!
[quote] Threads as well are mostly/completely unneeded, especially if we had solid support for the hardware timers available in our devices.
[/quote]
Well, I think support for threading is something important we would have to think about it before removing it…
I also agree that access to native (timer) interrupts would be a great feature. But we should take care to abstract hardware as good as possible.
a very big advantage of NetMF is that is is highly portable between platforms. I would design the future platform to keep this in mind.
Nevertheless, personally I could live with some NotSupported exceptions in the API on very cheap platforms where hardware is more basic…
It is (theoretically at least) quite portable, but I’d be pretty surprised if there were any working 4.3 ports for hardware other than the STM32 (GHI and Mountaineer) and the LPC hardware used by GHI.
There are only two platforms that matter; ARM9 and Cortex-M. I would argue that native speed would render the ARM9 platform irrelevant, now that STM has a Cortex-M with DRAM and LCD interfaces.
How about C# frontend for LLVM, such as GitHub - xen2/SharpLang: Compiles .NET/C# to native code using LLVM framework. No longer active, consider migrating to https://github.com/dotnet/corert or http://csnative.codeplex.com ? It is still needed to use linker from GCC, until lld fully supports ARM architecture, but it will get it…
Just as a matter of interest, csnative corlib is based on .NET Micro Framework’s one…
And there are a few RTOS-es for Cortex-M…
…and I’ve already revealed too much :whistle:
Maybe you are right. Nevertheless I would abstract the hardware with a HAL. If AOT is possible this HAL could be implemented in C#, too…
In my opinion users should have a convenient way to use the framework without understanding all the low level details. And if someone needs to dive into this low level area he could do this because of AOT and native access to the underlying hardware…
Sure, I wouldn’t do away with any of that. It’s the library that gives NETMF value.
The challenge that I see here is to make the library implementation as modular as possible, given the .NET API. At least for the device I/O I’d like to opt in individually for every device driver, and for IP I’d like to select exactly the stack(s) that I need. No dead code for abstractions that I don’t need in a project.
With an AOT compiler, I want to be able to write device drivers fully in C#. As it is right now, we have to use C/C++ for adding another Sockets implementation, for example. I’d like to be able to write one in C# instead, e.g. for a GSM modem. So we’d need an extension framework for socket providers, to which the standard .NET Sockets API is a façade. There exists no such extension framework in .NET at the moment, since Windows is assumed to address this on a lower level. Here we need some really well thought-out API design in the NETMF core.
Gadgeteer is not an alternative for me. It is not sufficiently modular I think, because its API already creates dependencies that an implementation is then stuck with, such as the assumption that every device knows about graphics.
Of course, also the .NET base class library was never designed for utmost modularity, so there are bound to be more dependencies than we would like, and some difficult-to-avoid dead code as a result.
One of the Chris Walker’s comments caught my eye:
Is this really so? NETMF team offloaded network stack to Secret Labs?
Oh my… Personally, if I were going to offload to anyone it would have been Cuno and his guys. They’ve demonstrated the most expertise in this area.