In another thread, the possibility has been raised that Microsoft may soon be doing much less development on NETMF. Let’s play a game of pretend, and say that’s true, and you fork the repository and start to make it your own. What do you do with it? The point of this thread is to dream the big dreams, chart many paths for NETMF, maybe hash out which ones might be worth pursuing.
1 Like
For me, I’d start by removing support for platforms that are not under current development. That would mean that support for non Arm platforms could be removed, and more likely non Cortex-M platforms, if that would simplify and streamline the PK.
I would love to see a simple open source multi platform IDE to program any NETMF device. No debugging is okay, even if this is a fork of arduino IDE. And even an online option like mbed.
As for the core, I see it complete. Ports for other processors would be very nice though.
I wouldn’t remove anything. I have learned a lot about HAL from it’s implementation for various platforms. I would start with bringing the documentation up to date. Would love to have very detailed and accurate documentation about PK. This will make creating more ports more easily.
2 Likes
Ok, I’ll bite on that game of pretend. I am a huge advocate of NET MF, but we need a boost. I think we’ll have cheaper and faster CPUs in the next 2 years (a wild guess). I think NET MF will no longer be necessary in a few years and we’ll be able to run stripped down versions of Windows or Linux.
I have been keeping an eye on Linux and Mono. Raspberry Pi proves that a Linux based system can be inexpensive. Once there is a chip that can boot Linux + Mono in 10 seconds or less and incorporates on-board RAM and Flash, I think the community should seriously look at it. I think long term, maintaining Mono could be a better bet than NETMF. And we’d get generics, LINQ, and robust networking.
Although, by the time that works, we might have an embedded Intel x86 CPU that could just run MinWin (Windows Core) and full-blown .NET or Compact Framework… Microsoft would have to figure out a way to license this though because nobody will pay more than a couple bucks (if that) for an embedded OS.
I hope I didn’t derail the conversation.
-Valkyrie-MT
@ Valkyrie-MT - you will always find use for netmf. If Linux worked on the future $5 chip, netmf will run on the $1 chip then.
There’s someone who has Windows CE running on the Pi, at least booting. Only question I guess is what the licenses would cost…
Without advanced debugging and an IDE that looked like Arduino’s, what would NETMF really be? Unfortunately, I don’t see NETMF really existing without Visual Studio and I don’t see Visual Studio going multi platform anytime soon. There probably will be an online version in the near future (1-2 years). Would anyone really use NETMF if it didn’t have Visual Studio?
I read an article the other day that was based on a good tip that Microsoft will be releasing Windows RT & Windows Phone OSs for free in the near future. I think it will happen. It almost has to if they’re going to compete with Android. Perhaps the WP OS becomes the new WinCE?
With so many other advanced embedded options available today that are so much more popular, perhaps if would be more productive if we were asking how we can bring the best of NETMF & Gadgeteer to one of them?
I couldn’t agree more. The main value proposition of NETMF is that it is built on the tools and languages that .NET developers are already familiar with. Take a big chunk of that away, and all you have is a slow, expensive Arduino with hard to work with sockets and support from only one company?
That would be wonderful. Someone has already done a lot of the work required to make CE run on the Pi.
Indeed. It’s my belief that one of the faults of NETMF is that it tries to be too much to too many, and ends up falling short of where it could be. In my opinion, the big beefy chips with external memory are the domain of CE, Linux, mono, NETCF, etc. NETMF could benefit by concentrating on the small, highly integrated solutions. The problem, most users don’t get excited about those solutions, they get excited by big MHz numbers. Problem is, the cheapest NETMF board is more expensive than the Pi, now, and that’s without all the extra stuff you would have to add on to get feature parity. In my not-so-humble opinion, it’s clear that NETMF can’t compete in that space successfully.
Sorry, I’m way off topic, now. Ask this is to say, that if I forked the project, I would concentrate only on the small end, and would drop anything that compromised the small end in order to support the high end.
What about making NETMF only 3x (not 30x) slower than native code? There was discussions about JIT compilation that is not possible due to constrained resources, but maybe times changed with all those boards with external RAM?
I wouldn’t give up Visual Studio for anything, but I thought Mono has a Visual Studio addin that allowed you to use Visual Studio to build Mono Apps.
Ok, back to .NET MF. I would LOVE to see the unused Flash on the chips used for project files that are included. That way, I could include files like html files and when I deploy the included files get deployed with the app. Then, I can enumerate the files and read them from within my app without having to add another flash chip and figure out a file system. Also, support for application settings would be great.
Isn’t that the same as adding files as resources?
I would add more code compability to big .NET.
Also support for multi core processors would be nice. May be with the ability to bind a thread exclusively to a core. Also running native code (like RLP) on an extra core would be interesting. Hard realtime on the one, and managed code on the other side.
A block of shared memory is a must have for this too.
I know I could achieve this with RLP timer interrupts, but it’s not really the same.
Also native support for multiple network ports would be great.
JIT compilation is also something I would give a 2nd chance
Most of my two cents are a repetition of godefroi’s statements. In particular, the raison d’être of NETMF is that it extends the scope of C# and Visual Studio down to microcontrollers. Triggered by direct customer feedback to this effect, I’ve recently added a visualization on our Mountaineer site:
http://www.mountaineer.org/netmf-for-stm32/
For high-performance embedded microprocessors, it makes more sense to use Linux or Windows CE. As Linux is free and maybe even more importantly is open source, the professional choice increasingly seems to be Linux. Mono might be a viable route on this platform. (Some of our customers are so invested in the .NET ecosystem that they contracted us to do iOS and Android app development in C# with Xamarin. This is not without problems, but has proven to be a reasonable compromise.)
I’ve seen projections that at least for the next five years, about two thirds of all shipped computer chips will be microcontrollers, and this is where I see NETMF. Maybe not with boards for hobbyists, as there is no way to compete with the economy of scale for a Raspberry Pi or Beagle Bone. But when it’s about doing professional low or medium volume custom boards with single-chip microcontrollers, then NETMF is cost-effective. Not least because both hardware and software complexity are much lower than for a Linux solution (e.g. you don’t have to fight the Linux driver model just to access a GPIO). Not to forget the lower costs for application development and maintenance over the years.
If I’d do a fork of the porting kit (basically this would just mean to copy some additional files from the Microsoft repository into our [em]NETMF for STM32[/em] repository), I’d go for the following:
-
Focus as much as possible. Get rid of distractions. Don’t copy any code that is not related to Cortex-M targets. Focus on headless devices (although good graphics completely within on-chip RAM is becoming more and more practical, so I’d take a second look at graphics again later on). This is not sexy. So be it.
-
Improve documentation, so that it becomes easier for new developers to learn how to create their own firmware versions, for their own custom boards. Not sexy.
-
I understand the wish for more ports and more choices regarding microcontrollers. There are some really interesting other Cortex-M products on the market, besides STM32. However, the Mountaineer group has by now invested more than two man years into developing NETMF for STM32, and we still expect considerable further investments to make this port as hassle-free as possible. Unless someone can stick to the most basic I/O features, they’d better make sure to have a competent team that can work on their own port for years to come. Of course a new port is always sexy. Unless you have to debug it.
-
Systematically go through the issues on Codeplex, prioritize and correct the relevant issues.
-
Reduce minor incompatibilities with the full .NET framework, e.g. in the Sockets API. But without making the footprint of the platform much larger.
-
Regarding features, the NETMF core is well-rounded as far as I’m concerned. With one major exception: for commercial Internet of Things projects, we need a fully robust (!) integration of a small embedded SSL stack into NETMF, preferrably not just with encryption but also with authentication. Maybe CyaSSL, PolarSSL or MatrixSSL would fit the bill. An SSL stack must be small enough so that it can be used e.g. on a 192 KB RAM microcontroller. It should provide the minimal number of algorithms that are sufficient to work with Microsoft’s Azure (no, Google fans won’t choose NETMF, so we’d better concentrate on Microsoft’s cloud services, see the initial argument). And it would require considerable fine-tuning for performance on the given microcontroller (I don’t like it if it takes two minutes to establish an SSL connection).
As can be seen from this list, there is a lot of work, much of it requires a lot of experience, a lot of time, and few developers would consider any of it “sexy”. I’m not at all interested in NETMF forks that are heroic flashes in the pan. I’ve seen too many cool projects started, and then their authors lost interest or didn’t have the time to keep going on. For that reason I’d forget about JIT, other IDEs, support for more architectures, multi-core or real-time support within NETMF.
4 Likes
You can add files as resources in NET MF?
And, I agree with Cuno on the SSL support. This is becoming more and more of a requirement for basic stuff to work.
It works for xml files (Glide forms) and bitmaps.
also RLP elf’s work like that.
It is file format independent feature.
Some of these things already exist, but I would like to see them brought into the core .NETMF.
[ol]Native BitConverter implementation
Native HashTable implementation
RLP as part of the core (Sorry GHI, but this was an awesome idea by you guys, that just needs to be promoted more, I know there are interoperability issues etc. but it does the job and it does it well)
Shared memory for manager + RLP code. This memory would not move or be compacted due to GC. I actually think that LargeBuffer might do the trick here, but I have not tested it.
Reduced bit depth Bitmaps
Improve WPF performance, or just remove it, there seem to be good libraries out there that do a better job.[/ol]
Pipe dream: (Not well thought through but might be fun to do)
I do not see JIT being a viable option especially for the memory constrained devices, however native compilation on the desktop might be a huge win. Let the .NET compiler compile to IL, then run a post process (NGEN?) which compiles functions to native code and stubs the IL bodies (The function and metadata will remain) with a call to the native version.
The compiling should be relatively easy, the trick will be TinyCLR will need to be able to handle load time address fix-ups to account for version differences etc. The post compiler will need to work with a well defined interface in the TinyCLR to handle the transitions from managed to native code and not be too dependent on the version of the desktop compiler.
I do think this would be achievable without adding much bloat to the core, especially if some of the actual interpreter code is removed since it will not be used. Being on the desktop, some additional optimization can occur like removing redundant bounds checks, variable hoisting etc.
The big trick will be handling the different chip, but if the as others have suggested this is limited to Cortex based processors this becomes less of an issue. And the compiler can be designed to have a mainboard driver that supports the compiler.
1 Like
@ taylorza - they call that AOT compilation - Ahead Of Time. The reason Microsoft gave for not implementing it was that native code is bigger than IL. I bet that’s not really an issue nowadays with our 2mb-onboard-flash chips.
That single feature would single-handedly remove the biggest disadvantage that NETMF has- the interpreted code performance penalty. Add the ability to handle hardware interrupts with managed code, and you’re set. It also eliminates the need for RLP.
I also think WPF could go- if you want complex graphics, there are better suited boards for that (and much cheaper as well!). One can build the firmware without WPF, though… Cerberus doesn’t have it, for example.
I think if all energy was concentrated on making one single mainboard with very good documentation and examples and on which every single feature worked flawlessly, then it would be a huge boost to people’s confidence in using NETMF. I do not think it is so important that if works with the latest Visual Studio or other platforms… only that it works perfectly and the documentation is clear and concise.
Therefore I would vote for less diversification and more emphasis on perfection.
4 Likes
About supporting latest/different VS Versions:
Generally it’s not that difficult to create a plugin that works with more than one VS version. Specially VS2012 and 13 means only changing on setting and rebuild.
I don’t know why the NETMF SDK is always built for one specific VS version. May be MS wanted to promote the newer VS version by this.
In fact it keeps people on sticking with Netmf 4.2 to still be able to support VS2010.
So one more point for the list:
Multi VS Version support for the latest SDK, lets say the latest 2 or 3 versions.
Plus a rebuild of the SDK when a new version is released in the meantime.