What would you do with your fork of the NETMF?

Yes, even if C# programs were compiled directly to ARM native code, breakpoints and symbolic debugging would still be possible.

With the ARM Thumb2 instruction set, the size overhead compared to CIL instructions (the .NET intermediate code) would be minimal, if any, so the code size issue has pretty much vanished.

Unfortunately, a C# AOT compiler is a large project. There have been several attempts as far as I know, but none targeted at Cortex-M (i.e., Thumb2 instruction set). A couple of years ago I’ve briefly been in contact with Chuck Thacker of Microsoft Research about such a compiler they’ve been writing at the time, but I haven’t heard of that project again. We considered writing one ourselves, but we knew out of experience how much work this is from our earlier compiler work. Thus we opted to contribute to NETMF instead of doing our own thing.

How much would be the difference in creating a AOT compiler for NETMF compared to ‘normal’ …NET?
Or is there anything else that would speak against it.

Thinking of that, COSMOS comes back into my mind:

Thumb2 is very different than x86, so it’s a big project. Some of it has been done, though, I believe, in the form of a native compiler which is kinda left hanging in the PK.

There’s also the fluent interop project that had traction for a while over in the Netduino community.

We can’t count on Microsoft for help, though. Given the recent news, I think we ought to keep our expectations low on that front.

What we really need is a group of students looking for a really ambitious final project for their compiler theory class…

I’m not so ambitious as you guys are :slight_smile: I’m working with Microframework .NET just few days and I would fix few things that are just pure wrong and make me feel like I’m developing in JAVA and not C#…
I would change this things:
[ul]Add EncodingUTF8.GetString and deprecate GetChars in future remove GetChars if its really so space critical…[/ul]
[ul]Microsoft.SPOT.ResourceUtility public static object GetObject(ResourceManager rm, Enum id, int offset, int length); replace with public static int GetObject(ResourceManager rm, Enum id, int offset, byte[] buffer, int bufferOffset, int length); so I can know when end of file is and GC don’t have to create multiple byte arrays. Or even better if posible make FileStream work on BinaryResourceFiles…[/ul]
[ul]http://netmf.codeplex.com/workitem/1388 (workitem 1388)public static method Convert.ToBase64String has two functionalitites and it’s working based on public static bool System.Convert.UseRFC4648Encoding? How about some thread safety? Multi library? This is pure WRONG.[/ul]

I had to do this for now:

                byte[] bytes=null;
                if (System.Convert.UseRFC4648Encoding)
                          bytes=Convert.ToBase64String("TEST");//Some more code in my case which can throw exception
                        System.Convert.UseRFC4648Encoding = false;

Few days and already bugs I never seen in Desktop .Net :frowning:

I wish some guys would make project on Github where we could make PullRequests and fix stuff like this and really get OpenSource thing going…

Isn’t this what Windows Embedded is? A modular version of full blow Windows designed for devices. We already have the option of the full-blown .NET framework on Windows Embedded. And Windows Embedded Compact 2013 runs ARM, Intel and SH. …Right?

Can’t we start doing this now? It seems like we just need a working Wiki for NETMF, and then we all need to get behind it.

I started this on our old wiki and then moved it to an ebook. I got very little help then. I hope more happens this time.

@ Gus - Has GHI received many community contributions to the GHI OS firmware base?

Not really and I think it is because the core is not easy to takle and most users just want to enjoy the use of VS.

Even when it is a bug, we haven’t seen significant contributions. At least nothing I remember.

@ Mike - I seem to remember Gus saying somewhere that they are not really geared for accepting community contributions. Otherwise trust me I would contribute, I have a Signal Generator implementation for the Hydra that I am sitting on. I can also understand the burden it would put on GHI to ensure the quality of the contributions.

It would need to be community driven and we know how little success that has seen, we have 2 community initiatives that I am aware of and I do not think there has been much uptake.

Gus, are you opening the door :slight_smile:

Yep. I think this has been a major deterrent. There isn’t a lot of motivation to contribute when people don’t think they’re actually contributing to the project. Not only does GHI have to worry about the quality but they also have to worry about contributions conflicting with their features that they sell as “premium” (ex. SignalGenerator).

This all goes back to a point that we discussed months back which is the OSHW offerings are OSS but NOT open source projects. If the current source (including dev branches) were available then we could test and contribute in real time instead of waiting for GHI to take their best stab at it and us testing again after they decide to release. Same problem with the NETMF core from Microsoft. Not finding out what’s in a release until after its released is not really being open. Unless you work for the current U.S. executive/congress…

Just to be clear, I was not being negative about GHI’s approach, as I said I understand the burden a true open source approach would put on them.

While there are many theoretical value propositions for them adopting or formally supporting a true open source effort, current adoption of community versions, or lack there of, in my mind at least, disproves many of those theories.

But what we as a community could be doing is delve into the firmware and push fixes back to GHI. Initially via the forums, but I would hope that if this shows real value for GHI they would eventually define a formalized approach…

Sorry for going off topic, but I wanted to make sure that I was not misunderstood.

Those contributions that have been made have not been accepted, and to be sure, GHI is under no obligation to accept them. There certainly is a community port available right now, and I think it’s even on github. There has been rather little activity, I think. It would be great if GHI would adopt it as the official firmware (it is more feature rich), but that won’t happen, because it’s 4.3 and that means Gadgeteer is out.

It would be trivial to fork it and change the header to be able to deploy directly on an unmodified F4DISCOVERY. That’s probably the best bet it’d any of this is to lead to action.

To all, we have always welcomed and willing to support a community port. This is still open and it does not rely on any company, as it shouldn’t in my opinion, not ghi and not even Microsoft.

The community has always talked about interest, just like now, and we are still waiting to see this happening. So will someone get the ball rolling this time?

@ godefroi - can you not be so negative just once! Yes 4.3 will be fine for gadgeteer! So please start the port and we will gladly provide the needed updates to the drivers.

@ Gus - had I wanted to be negative, you left me the perfect opening. I didn’t take it, because that horse has been beat to death and having this devolve into another name calling shouting match serves nobody.

As I understand it, GHI does not move to 4.3 because there is no Gadgeteer release for 4.3. Is that incorrect? No negativity intended here.

There is. The Mountaineer Firmware 4.3 Beta 1 supports it: http://www.mountaineer.org/resources/release-4-3/. Of course, this firmware would be more useful if there were also 4.3 drivers for the various Gadgeteer modules.

Btw, once we get Microsoft’s QFE 1 software we will do a Beta 2 release.

1 Like

There certainly is a community port available right now, and I think it’s even on github. There has been rather little activity, I think. [/quote]

Yes, it’s here: GitHub - NicolasG3/NETMF4.3_Community: NETMF 4.3 Community features and GCC compatibility

There’s a Wiki too.

Funny, when this thread got started, I actually started making my own changes to it after Reinhard Ostermeier pointed out that Embedded resources work in NET MF. I made some changes to allow for enumeration of the Resources (https://www.ghielectronics.com/community/codeshare/entry/844). Also, I just got finished shrinking the tinybooter to free up sector 3 (16kb) for use with the InternalFlashStorageClass in codeshare. Now I can persist 16k of settings into flash! I am going to wrap that in another class that only persists changes periodically to avoid too much flash wear. I’ve never used github though, so I don’t really how to contribute my changes.


@ godefroi - gadgeteer does support 4.3 like others pointed out and we talked internally about adding the support, needed for mountaineer boards and community firmware etc. And it will be already there once we release 4.3 firmware in the future, so it is good to have anyway.

Of course, we do not need to do any of this as our code is open source but we would love to and want to help.