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.
I’m not so ambitious as you guys are 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:
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
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?
@ 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.
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.
@ 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.
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.