Question - Types of target platforms

[Korporal]

Could the team consider adding some clarifications to the about page? I'm speaking of the kinds of target platforms that are supported. It seem that the IOT libraries and the .Net Core runtime require an operating system to be present like Windows or Linux, is that the case?

Can the IOT libraries be used on more resource constrained devices like for example this microcontroller board?

Why is the OS needed any way? is it not possible to load some basic firmware that can host the runtime and then simply run the .Net code?

[krwq]

Hello @Korporal, we currently are doing some work toward making it work on nanoFramework which works on i.e. ESP32. @Ellerbach will have more details

[pgrawehr]

@Korporal Executing C# code requires the .NET runtime, which, in its basic form, is about 150MB in size, which is far beyond what typical microcontrollers offer. A decent amount of RAM is also required. All boards that have these specifications can run an operating system, so they're running one. The nanoFramework project has the goal to provide a significantly reduced runtime that can be installed on microcontrollers.

[Ellerbach]

@Korporal you can check .NET nanoFramework (see https://github.com/nanoFramework/Home) to run .NET on micro controller. We're currently aligning .NET IoT and .NET nanoFramework API to make it easier to reuse code from one to the other platform. In few weeks, we'll as well migrate some of the .NET IoT binding to .NET nanoFramework. Again, nothing will be magic, some of the bindings won't just work because of the constrains of the micro controller and some limitations in .NET nanoFramework.

[Korporal]

@Ellerbach - Hi, and thanks, yes I've explored nanoFramework and was going to contribute at one point too. The biggest problem is that this is stuck in the past, there's no support for generics for example and many of the recent innovations in the C# language are not necessarily supported either.

Also the entire architecture of the proposed nanoFramework libraries is unclear, seems undefined, there was some indication it was to be based on UWP but that was not clear nor is it clear exactly what contracts many of the UWP endpoints are expected to adhere to either.

[pgrawehr]

@Korporal May I ask what kind of projects you intend to build? I do have an alpha version of a new runtime implementation for microcontrollers that can run the full .NET 5 framework (with all C# 9 features) and possibly most of the bindings here, but I don't think it's production-ready yet (lots of open ends). And support for the ESP32 is not complete, too. But if you're interested in some engineering work and low-level debugging, it might be an option.

[Korporal]

@Korporal May I ask what kind of projects you intend to build? I do have an alpha version of a new runtime implementation for microcontrollers that can run the full .NET 5 framework (with all C# 9 features) and possibly most of the bindings here, but I don't think it's production-ready yet (lots of open ends). And support for the ESP32 is not complete, too. But if you're interested in some engineering work and low-level debugging, it might be an option.

@pgrawehr - Really? that is very interesting indeed. My motive was mainly to be able to work with C# in the development of code where I can write code on these devices using the same languages and tools that are used on the desktop or other platform.

An example of this might be a "robotics" application where I could develop a rich functional control system that runs on my desktop and have that interact with external MCU boards (over WiFi or other radio technologies) whose code is also written in C# perhaps even sharing binary assemblies even.

Take the Nucleo 64 board, that has numerous peripherals available like DA and AD converters, UARTs and so on, today any code I write for this must be in C (or the dreaded C++) and although I'm a very seasoned C software developer the necessity to work with two quite different languages adds a considerable burden I find.

What you describe above sounds impressive, much of what I've found recently implies this is not really possible or there's just no interest so I am very curious yes...

[pgrawehr]

@Korporal I'll get back to you tomorrow. I need to clean up a few things (including a bit of documentation on how to get started).

[Ellerbach]

The biggest problem is that this is stuck in the past,

I tend to disagree with this :-) It's modern!

there's no support for generics for example

This is coming very soon. Stuck with some debug problems related to VS which are about to be solved

many of the recent innovations in the C# language are not necessarily supported either.

Which ones? :-) The tool chain used to build is the same as for "normal" framework. Limitations are with non supported classes like generic (again, it's coming soon) and things like linq. But nothing that you can't do with something else.

Also the entire architecture of the proposed nanoFramework libraries is unclear, seems undefined, there was some indication it was to be based on UWP

We're moving away from the UWP API to align with the .NET IoT ones. That's now very clear. 2 more needs to go Pwm and SerialPorts. Spi, Gpio, I2c is done already.

[Ellerbach]

Take the Nucleo 64 board, that has numerous peripherals available like DA and AD converters, UARTs and so on, today any code I write for this must be in C (or the dreaded C++) and although I'm a very seasoned C software developer the necessity to work with two quite different languages adds a considerable burden I find.

For this board, you already have all this supported and exposed in C#

[Korporal]

Take the Nucleo 64 board, that has numerous peripherals available like DA and AD converters, UARTs and so on, today any code I write for this must be in C (or the dreaded C++) and although I'm a very seasoned C software developer the necessity to work with two quite different languages adds a considerable burden I find.

For this board, you already have all this supported and exposed in C#

Hi @Ellerbach - This seems to be saying that there's a build of the .Net Core CLR that has been tested and runs on the Nucleo board, but is that correct? are we understanding each other here?

[Ellerbach]

This seems to be saying that there's a build of the .Net Core CLR that has been tested and runs on the Nucleo board, but is that correct? are we understanding each other here?

You have a .NET nanoFramework build for the Nucleo 64, see https://github.com/nanoframework/Home with support for ADC, DAC, PWM, I2C and more! It's not .NET Core. .NET Core won't work on it, the MCU is too small. It's .NET nanoFramework. To make it simple:

• CPU = .NET Core
• MCU = .NET nanoFramework

Difference between MCU and CPU is speed of the clock, RAM. I hope this is more clear and helps!

[Korporal]

@Ellerbach - I may not have explained myself clearly. I want to be able to write C# code that includes support for generics and all new C# language features AND be able to run this on boards like the Nucleo. Im aware of .Net Nanoframework, I've used it and used it on this and other boards.

.Net Nanoframework is dated and cannot support generics and there's no plan or goal to make it do that so far as I am aware.

So I'm trying to understand if MS are able to or concerned with, creating a version of the new .Net Core CLR that can run on these resource constrained boards without the need for a full blown OS like Linux or Windows.

Does this make my position a bit clearer to you?

Thanks

[Callum6677]

.Net Nanoframework is dated and cannot support generics and there's no plan or goal to make it do that so far as I am aware.

So I'm trying to understand if MS are able to or concerned with, creating a version of the new .Net Core CLR that can run on these resource constrained boards without the need for a full blown OS like Linux or Windows.

If you are to reread the above, you'll see that nano framework does support most new C# language features and that support for generics is coming soon.

I dont believe there is any plan for a version of full netcore clr (which depends on an applications OS) for mcus. Even nanoframework relies on an OS, just it uses a lightweight RTOS instead.

[joperezr]

@Korporal I apologize if we are not understanding your ask clearly, and just wanted to let you know that we appreciate you bringing up this discussion as it is beneficial to the .NET platform.

MS are able to or concerned with, creating a version of the new .Net Core CLR that can run on these resource constrained boards without the need for a full blown OS like Linux or Windows.

Not that I'm aware of. For boards like that, most of our focus today is based on helping NanoFramework to close that gap for the features that are not there yet, like generics and such. There are many MS engineers that contribute to nano framework (@Ellerbach is one of them 😄) in order to help modernize the platform. I see that you have worked with nano framework before, but do note that as it has been shared earlier, there is an ongoing push to modernize the platform so it may be worth it for you to explore again once they have generics support.

I hope this sort of answers your question but if not, please let me know.

[Korporal]

@Korporal I apologize if we are not understanding your ask clearly, and just wanted to let you know that we appreciate you bringing up this discussion as it is beneficial to the .NET platform.

MS are able to or concerned with, creating a version of the new .Net Core CLR that can run on these resource constrained boards without the need for a full blown OS like Linux or Windows.

Not that I'm aware of. For boards like that, most of our focus today is based on helping NanoFramework to close that gap for the features that are not there yet, like generics and such. There are many MS engineers that contribute to nano framework (@Ellerbach is one of them 😄) in order to help modernize the platform. I see that you have worked with nano framework before, but do note that as it has been shared earlier, there is an ongoing push to modernize the platform so it may be worth it for you to explore again once they have generics support.

I hope this sort of answers your question but if not, please let me know.

@joperezr

This is much appreciated and clarifies all this, thanks to each of you for explaining all this.

The last time I looked at NF (about two years ago) it did not seem to have any MS involvement and seemed more like an effort to just expand the API surface using UWP as the definition.

From what you say there is now more MS involvement and participation than I thought so perhaps I should take another look now at NF!

Thanks

[Korporal]

@Korporal you can check .NET nanoFramework (see https://github.com/nanoFramework/Home) to run .NET on micro controller. We're currently aligning .NET IoT and .NET nanoFramework API to make it easier to reuse code from one to the other platform. In few weeks, we'll as well migrate some of the .NET IoT binding to .NET nanoFramework. Again, nothing will be magic, some of the bindings won't just work because of the constrains of the micro controller and some limitations in .NET nanoFramework.

Hi @Ellerbach - My confusion stemmed from simply not knowing that MS were more involved in the NF project, I worked briefly with this about two years ago and even submitted a pull request (or had someone else do the change) for some low level oddity that I found.

I'll certainly take a closer look now that you've brought me up to speed.

[Korporal]

I seem to also recall chatting so some people on Gitter, there was a room I recall and I think it was Gitter but this doesn't seem to exist, so I must be confused again...

Ahh OK it was Discord, March 2019 that's when I was actively looking at this.

[Korporal]

Its coming back to me now, here's stuff I was looking at back then:

https://discord.com/channels/478725473862549535/542359989113847838/543896121374670859

[Korporal]

OK I actually spent quite a lot of time back then looking at stuff, if this is of relevance my posts can be found using this search in Discord from: KorporalKernel#4164

I recall being puzzled about async being supported, is it now supported?

Thanks

[Ellerbach]

I recall being puzzled about async being supported, is it now supported?

You are right, async not (yet) supported.

[joperezr]

Given that the original question that drove this discussion is now answered I'll go ahead and close this issue for bookkeeping purposes. @Korporal feel free to reopen if you feel it is necessary.

[Ellerbach]

And @Korporal some reading about .NET nanoFramework and the recently added test framework: https://devblogs.microsoft.com/dotnet/show-dotnet-build-your-own-unit-test-platform-the-true-story-of-net-nanoframework/

[Korporal]

And @Korporal some reading about .NET nanoFramework and the recently added test framework: https://devblogs.microsoft.com/dotnet/show-dotnet-build-your-own-unit-test-platform-the-true-story-of-net-nanoframework/

Thanks @Ellerbach, this looks very interesting, seems you guys are doing some very serious work on this!

[pgrawehr]

@Korporal : I wasn't able to get things in a good shape yet, but an approach you can try already is using the Arduino binding. This uses an Arduino (or another supported microcontroller) as a hardware interface to a PC. The program will run on the PC (and can therefore use the full .NET Core stack), while the hardware is connected to the microcontroller. I now tested it also with WiFi, so it's possible to remote-control a robot. That should be exactly what you need.

Read the general documentation at https://github.com/dotnet/iot/tree/main/src/devices/Arduino and be sure to use the ConfigurableFirmata version from https://github.com/pgrawehr/ConfigurableFirmata/tree/develop. If you've got any problems setting it up, I'll be glad to get feedback (maybe open a separate ticket on that).