.NET on embedded devices

[Hell-Lord]

Video: http://channel8.msdn.com/Posts/Whats-the-Micro-Framework/
MSDN link: http://msdn.microsoft.com/en-us/embedded/bb267253.aspx

Really interesting Video i just watched, thought others might be interested.

[abc]

Video: http://channel8.msdn.com/Posts/Whats-the-Micro-Framework/
MSDN link: http://msdn.microsoft.com/en-us/embedded/bb267253.aspx

Really interesting Video i just watched, thought others might be interested.

Really, really neat find! Thanks!

p.s embedded fusion: http://www.embeddedfusion.com/

[Camel]

As someone who has actually written embedded software, I'm fairly disappointed with the level of detail they go in to in that video. A few of the questions I would have asked:

What hardware is on the prototyping board they showed?
What architechture and speed is the CPU?
Is there a clock? I don't mean a wall-time clock (they addressed that question), I mean a (configurable) crystal oscillator.
Does the CPU and framework support interrupts?
If so, is the board pre-configured for any standard interrupts?
How many I/O registers (essentially, exposed pins on the CPU that you can drive via software) are there?
How many of those registers are left over after all the crap they put on the board?
Are there any UARTs? (A UART is what you use for a serial port; a more complex example of a UART would be a USB chip)
Is there a chip to drive the display, or is that handled by the framework (sketchy!)?
How much RAM is there?
Is the display touch-sensitive?
Is the application code stored in ROM?
Is the API/interpreter code stored in ROM?
What type of ROM?
What are the power limitations of the board, as provided?
Could I, for example, use the power source to power a small motor, or would I have to add a new supply?

It does sound like they have solved all of the difficult things about being an embedded programmer, but that sounds too good to be true. I find it hard to believe that software (their emulator) will be able to account for things like current leaking across the PC board, resistors overheating, capacitors overcharging, relays bouncing, the accuracy of R/C time constants (since, in the real world, these tend to vary since no two components are really identical), a wireless card having poor signal, or any number of other things you would be able to test with real hardware. These are just a few of the reasons that real companies don't even attempt to use software emulated hardware.

[Hell-Lord]

There are more videos to come though, they might answer more then.