.NET micro framework ... end of embedded world???
in [Embedded]
|
From: Simon Clubley on 11 Dec 2009 07:52 On 2009-12-10, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: > > MS has shown time and again that it simply does not understand about > embedded systems - Wince is a total and utter fiasco considering the > money and commercial muscle behind it. I see no reason to suspect that > this attempt will be any different. > One thing I have not seen discussed yet: What are the realtime capabilities of C# ? Can you do hard realtime (as opposed to soft realtime) ? Can you guarantee that a section of code will complete execution within X clock cycles ? How do you estimate the number of clock cycles a section of C# code will take to execute ? What kind of latency is there before an interrupt handler written in C# starts executing ? (IE: does the interrupt have to pass through the runtime first ?) Simon. -- Simon Clubley, clubley(a)remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world
From: David Brown on 11 Dec 2009 08:23 Simon Clubley wrote: > On 2009-12-10, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >> MS has shown time and again that it simply does not understand about >> embedded systems - Wince is a total and utter fiasco considering the >> money and commercial muscle behind it. I see no reason to suspect that >> this attempt will be any different. >> > > One thing I have not seen discussed yet: What are the realtime capabilities > of C# ? > Perhaps someone who is familiar with using C# with low-level embedded systems can answer (if such a person exists). My guessed answers to all your questions would be "no" or "you can't". > Can you do hard realtime (as opposed to soft realtime) ? > > Can you guarantee that a section of code will complete execution > within X clock cycles ? > > How do you estimate the number of clock cycles a section of C# code > will take to execute ? > > What kind of latency is there before an interrupt handler written in > C# starts executing ? (IE: does the interrupt have to pass through the > runtime first ?) > > Simon. >
From: Jon Kirwan on 11 Dec 2009 09:24 On Fri, 11 Dec 2009 14:23:32 +0100, David Brown <david(a)westcontrol.removethisbit.com> wrote: >Simon Clubley wrote: >> On 2009-12-10, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >>> MS has shown time and again that it simply does not understand about >>> embedded systems - Wince is a total and utter fiasco considering the >>> money and commercial muscle behind it. I see no reason to suspect that >>> this attempt will be any different. >> >> One thing I have not seen discussed yet: What are the realtime capabilities >> of C# ? > >Perhaps someone who is familiar with using C# with low-level embedded >systems can answer (if such a person exists). My guessed answers to all >your questions would be "no" or "you can't". ><snip> The question might be more precisely phrased as, "What is the uncertainty of the execution duration (or start of execution relative to an external or internal event) for a given code fragment considered 'important' to an application?" What makes my day is being able to _know_, a priori, that some code will execute over some finite, predictable duration and/or that some code will begin execution relative to some event with some predictable delay. Preferably where execution times are predictably within a required window and delays consistently within the range where I need them. (On some processors, like the ADSP-21xx, a timer interrupt event will reach the first instruction of the interrupt vector with zero cycles of uncertainty -- it is _always_ exactly the same delay each and every time relative to the cycle where the timer overflows. Now that is beauty to me.) I suspect c# has it's meat-and-potatoes applications where .NET has features important to the application. What makes c# _not_ so good, to me, is the garbage collection -- I gather this is mark and sweep and, if I remember correctly, this method effectively suspends the application during collection. Pretty much killing the idea of predictability, to my way of thinking, and thus it's suitability for real-time use. For folks with a .NET application that can tolerate mark and sweep GC, I say have at it. Jon
From: Mark Borgerson on 11 Dec 2009 10:25 In article <ecd41288-7b2b-4ebf-a4a8- f68651810ddd(a)w19g2000pre.googlegroups.com>, jim.granville(a)gmail.com says... > On Dec 11, 4:34 am, Andrew <asm...(a)blackstone.biz> wrote: > > > > I'm a developer. Just lost a project that could have been > > done with an AVR to ARM with micro framework. > > What was the project, and what volumes, and future-change targets ? > > Quite a few low volume applications, have a wide range > of possible solution candidates. > > > > > That is the topic of this thread. > > Are cheap 32bit micros going to displace 8bit micros? > > The cost difference is converging. > > Not quite, The thread topic seems to confuse Microprocessor, with > Microcontroller. > > Most high volume embedded designs, use Microcontrollers : Single chip > devices, with fixed Code and Ram. > The software also tends to be fixed. > > Microcontrollers use external memory, and commonly have operating > systems, and even .net baggage too. > On these systems, software update are common, and there are after- > market applications sold as well. > > Sure. the latter category ARE getting physically smaller, but they > will NEVER display Microcontrollers. > Ummm---- you just used the word "microcontroller" for two different systems. I think the second usage should have been "microprocessor". And you wonder why other people are confused!!!! ;-) Mark Borgerson
From: rwaltman on 11 Dec 2009 15:11
On Dec 11, 8:23 am, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > Simon Clubley wrote: > > > One thing I have not seen discussed yet: What are the realtime capabilities > > of C# ? > > Perhaps someone who is familiar with using C# with low-level embedded > systems can answer (if such a person exists). My guessed answers to all > your questions would be "no" or "you can't". Here we go again. Define "realtime"... ;) Can we use C# , for example, for a GPS mapping application? (such as Think Garmin,TomTom, etc. car nav toys.) Sure. Can we use C# , for example, for an aircraft autopilot? I wouldn't. (ignoring for the moment the issue of the underlying operating system) See "Performance Implications of Crossing the P/Invoke Boundary" for some of the pitfalls of using C# in an industrial control application. ( http://community.opennetcf.com/blogs/cf/200801/PInvoke/Performance%20Implications%20of%20Crossing%20the%20PInvoke%20Boundary.pdf ) For those unfamiliar with C#, "P/Invoke" (Platform Invoke) means calling a regular library or OS function ("not-managed") from C# code ("managed") In addition to the performance and timing issues discussed in the paper, P/Invoking also suffers from incomplete coverage (not all language data types are marshaled correctly), loosing any "object- orientation" across the call, (only plain old function style is supported) and don't even get started with issues such as memory buffers being relocated while transferring data to/from them. (Unless special precautions are taken) Of course, real or perceived C# limitations will not stop Microsoft from convincing managers that it is the way of the future, and those managers telling developers that C# is official language from now on. Roberto Waltman |