Mark H

As a .NET developer for around 10yrs now, I am happy to support Chris in saying that no form of .NET or any managed language can be use realtime. By real time we mean that you know exactly how long something takes to a clock cycle level - and it will always take that long, no matter what.

How do we know that .NET isn't designed to be real-time? The shortest amount of time you can hold execution up for without using IL is 1ms, and the sleep can be inaccurate by as much as 2-3 milliseconds - even on full .net on a 3ghz quad core. You have no single clock sleep, no nano or micro second wait. There is no guarantee that any given method call with execute at the same speed, at all times.




.NET has always been designed to be a fast to write, easy to use, quick to develop smart language. .NET is slow, it's not going to be as fast as C, never mind ASM optimised C. .NET takes care of all the hard stuff for you - memory, object life cycle, eventing, threading, error handling, etc. This is where it excels. It is not designed to run a time-critical system such as a flight computer.

The wallstreet application previously mentioned won't mind if a piece of code runs 1ms too slow. This sounds like a minuscule amount of time - only 1/1000th of a second. In the embedded world, this may as well be a minute. When a basic dsPIC processor is capable of handling 40 million operations a second, and cheap ARM chips capable of handling well in excess off 300 million operations per second it puts things in perspective. If it takes you 1000 operations to toggle a pin (which would require some really dodgey code!) you can still toggle that pin in 1/300,000th of a second. Toggling pins is easy, now imagine some mathemetics and reading analogue inputs, taking some serial data, i2c data, etc. Say this is 3000 operations. That code can execute 13,333.33 times per second on the basic dsPIC processor.It will always execute at this speed, every single time. It will always take 3000 operations, no other operations will occur other than what you've written. In .NET, the same code might execute 2000 times a second, or only 500... it's totally random, unpredictable, and uncontrollable - this is the issue.

I've seen a couple of threads about the board and schematic files and people wanting them in Eagle, is anyone interested? I'll port them over if there is enough interest - i have an Eagle Pro license so the 4 layer restriction is no problem to me. I have a feeling i'd have to do a redraw from scratch, so the routing will be different however components should mostly be in the same place (all the important stuff anyway) - it would be enough for using to generate your own netduino based devices in any case.