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.
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 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");
}
else
{
try
{
System.Convert.UseRFC4648Encoding=true;
bytes=Convert.ToBase64String("TEST");//Some more code in my case which can throw exception
}
finally
{
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.
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.
[quote=âgodefroiâ]
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]
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.
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#âŚ