Linked by Thom Holwerda on Tue 13th Feb 2007 21:47 UTC, submitted by anonymous
.NET (dotGNU too) Microsoft officially released the .NET Micro Framework Software Development Kit, today. The new, low-end member of Microsoft's embedded software lineup extends the company's reach into high-volume, cost-sensitive devices and subsystems with severely constrained processor and memory resources.
Order by: Score:
.NET and Embedded
by CrazyDude0 on Wed 14th Feb 2007 01:15 UTC
Member since:

I don't know why but this combination makes me scared...have you guys ever seen a fast small light-weight .NET program?

.NET is good for UI based applications but it does not make much sense in high performance or low resources applications. I don't know why Microsoft is so hell bent on pushing .NET our throats...similar to like how SUN was trying with Java..

In my experience interpreted languages are good for things like scripting and UI but not at all for big applications that need high performance like for example a media player etc...

Reply Score: 2

RE: .NET and Embedded
by rayiner on Wed 14th Feb 2007 02:20 UTC in reply to ".NET and Embedded"
rayiner Member since:

You'd be surprised how low a VM can go. The desktop (really, server) CLR and JVM are pretty heavyweight, but that's largely because they trade memory for execution speed. An embedded JVM can make a different set of trade-offs. First, the JIT can be small and simple. Embedded CPUs are usually single-issue designs with short pipelines, so you don't need the overhead of a fancy optimizer. Second, you can leave most code as bytecodes, JIT'ing only critical inner loops that fit into the cache. On an embedded platform, memory is both slow and expensive (16-bit memory bus, usually). So leaving most things as bytecode, which is much smaller than machine code, saves both time and money. Third, many embedded CPUs like an MMU, and consequently memory protection. Thus, the "safe code" guarantees of a VM help both stability and security.

The JVM has proven to work quite nicely on embedded platforms --- most newer phones have a JVM of some form or the other.

Reply Score: 4

RE[2]: .NET and Embedded
by BrianH on Wed 14th Feb 2007 19:54 UTC in reply to "RE: .NET and Embedded"
BrianH Member since:

Most of your comment is right on the mark here, but...

Third, many embedded CPUs like an MMU, and consequently memory protection.

The article states that .NET MF supports CPUs without an MMU, so it must handle memory protection some other way.

Reply Score: 1

RE[3]: .NET and Embedded
by rayiner on Wed 14th Feb 2007 21:30 UTC in reply to "RE[2]: .NET and Embedded"
rayiner Member since:

That was supposed to be "lack an MMU" not "like an MMU". My point was that since C# programs cannot cause out of language errors, some level of program isolation can be achieved even without a hardware MMU.

Reply Score: 2

RE: .NET and Embedded
by flanque on Wed 14th Feb 2007 03:53 UTC in reply to ".NET and Embedded"
flanque Member since:

I can understand why you'd say that, but really, I'd bet that an embedded .NET would be much tighter, neater and cut back. It really doesn't have much choice to be anything other than that.

Reply Score: 3

C# only?
by load_mic on Wed 14th Feb 2007 15:02 UTC
Member since:

There is only mention of C#. What about other .NET languages?

Reply Score: 1

by zhulien on Wed 14th Feb 2007 15:20 UTC
Member since:

I'm thinking how is a VM going to run on a Z80 with 1kb of RAM and 16kb ROM attached to it?

Reply Score: 1

RE: hmm
by mrcool on Wed 14th Feb 2007 15:57 UTC in reply to "hmm"
mrcool Member since:

I think Zork's Z-Machine VM works on a Z80! ;)

Reply Score: 2

Member since:

Most embedded software has real-time requirements. This means that for certain tasks it must be possible to guarantee that they finish within a given time. This is possible when using a language like C++ on operating systems like Linux RT or Windows CE, since the C++ language does not perform garbage collection, and since there are upper limits defined on the time the OS spends inside an interrupt. Garbage collection is an essential part of the .NET CLR however. Does Microsoft guarantee anything about the real-time behavior of the .NET micro framework ?

It is right that most new phones contain a JVM. But is the JVM used for more than games in these phones ?

Reply Score: 1

rayiner Member since:

According to the FAQ, the micro framework is not real-time. However, that's probably less a function of the language and more a function of development priorities. It's entirely possible to create a GC that has bounded pause times. IBM's Metronome has pause times on the order of a few hundred microseconds, which is good enough for most soft-realtime tasks, including audio and video.

In general most good incremental collectors have a maximum pause time that's a function of things like the stack size, register count, static data area size, and maximum array size. In real-time applications, these will all be known, bounded values. As a result, your 99-th percentile GC pauses will be bounded. Now, 99th percentile isn't good enough for some things (running a nuclear reactor), but it's good enough for a lot of other things.

Reply Score: 2

by knightrider on Wed 14th Feb 2007 19:02 UTC
Member since:

The smallest thing I've ever seen them do is Windows CE...If only they would shrink the binaries down for XP or Vista we'd have a small footprint OS that runs much faster than what we have today...

Reply Score: 1

In the Real World
by jo42 on Thu 15th Feb 2007 17:13 UTC
Member since:

Our embedded programmers are optimizing critical code in assembler on the target platform and finding that in most cases the code the C/C++ compiler generated is actually better than the stuff they wrote due to its better knowledge of the processor.

In their opinions, .NET C# and CLR is a bad joke pooped out by people that have never had to write code for real world embeded hardware such as cell phones and digital cameras...

Reply Score: 1