"C# is intended to be suitable for writing applications for both hosted and embedded systems, ranging from the very large that use sophisticated operating systems, down to the very small having dedicated functions." -- design goals (wikipedia)
Although it greatly depends on how embedded is "emebedded",
How well do you think C# has reached this goal?
Do you consider C# to be just as good if not better tool for the job than C/C++?
Well, there is Micro Framework; I don't hear a lot of noise about it, but I'm not into "embedded". But it would depend on what it was doing... C# is a good general purpose language, but there are still times when something hard-core is needed (and hang the code-complexity).
There are lot of commercially successful software applications written in C# and for the WinCE platform. For example, some set-top-boxes (from AT&T etc) run C# code on .net CF. Given these boxes have 64 or 128 MB ram, I think C# in embedded is embedded enough.
Point is with advancements like hardware accelerations and other compiler advancements a JITed language like C# are able to good job.
And the greatest advantage is with latest Visual Studio you are able to debug the device from VS. At least for a dev environment, there is nothing as good now.
note: platform wise there are lot of competitors for WinCE/ WinMobile and each has its strong point. In above I am only talking about the dev environment advantages.
As you know, you need to have an embedded .net mini runtime if you want to write your code against it, in C#. You could say, like Win CE.
I hope we'll have low cost .NET mini-mini embedded chips soon in market, or are they already there? Just a little bit interested about this news
http://www.windowsfordevices.com/news/NS4666205829.html
A small startup in Microsoft's backyard is poised to begin shipping a tiny, 32-pin chip-like computer module that runs ".NET Embedded," a new Microsoft embedded software platform developed for use in watches and other "smart personal objects." The module, developed by startup .netcpu Corp., incorporates portions of Microsoft's Smart Personal Objects Technology (SPOT) hardware and software.
How ever, here is something interesting for you. Have a look at the COSMOS project. It can translate your IL code to various platforms (and in future to embedded architectures hopefully)
http://www.gocosmos.org/index.en.aspx
Cosmos includes a compiler (IL2CPU, which is part of Cosmos) that reads the input file (usually the shell) and Cosmos libraries and compiles the resulting IL to x86 code. IL2CPU has a layer for cross platform and we plan to support other processors and platforms, including x64. IL2CPU also supports certain extension methods which allow C# code to interact directly with the CPU, registers, and ports in the kernel. IL2CPU contains some inline assembler, but there are no ASM files that need to be linked in.
Currently IL2CPU first outputs raw asm files (with IL comments) and then processes them through nasm (a free assembler). Later we plan to emit directly to binary.
What would be interesting to do is create a 'compiler' that turns a .Net Micro Framework assembly into a native embedded assembly language. It'd have to inject memory management calls into the methods, though. Alternatively, instead of trying to 'guess' where they go, you could have a psuedomethod, say, System.Memory.Delete(), and use that as a sign to insert deletion there.
It would be an interesting thing to try with the Phoenix framework; I might just try it out next holidays.
Check .net micro framework http://www.microsoft.com/netmf/default.mspx
I have a difficult time believing that c# would ever be an optimal choice for an embedded system, at least to the degree of processing horsepower that is available currently. C# typically targets down to MSIL/CIL rather than a suitable machine language. It is feasible that one could get machine code for a particular processor from c#, but is is unlikely to be terribly efficient. Best bet: stick to languages that lie closer to the hardware (c, c++, unmanaged), despite the lack of built-in memory management (as non-deterministic as it is) and limited range of available libraries. In embedded, pared-down and transparent is the best bet, imho.
Embedded systems quite often have real-time requirements. Satisfying those with a garbage collected language is likely to be intersting.