-jg wrote:> On Dec 11, 4:34 am, Andrew <asm...@blackstone.biz> wrote: > > 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.I'm sure you meant microprocessor on next line.> 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. > > -jg.NET micro framework WILL run on single chip microcontroller. http://www.ghielectronics.com/product/113 That is what this thread is about.
.NET micro framework ... end of embedded world???
Started by ●December 9, 2009
Reply by ●December 11, 20092009-12-11
Reply by ●December 11, 20092009-12-11
Andrew wrote:> -jg wrote: >> On Dec 11, 4:34 am, Andrew <asm...@blackstone.biz> wrote: >> >> 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. > > I'm sure you meant microprocessor on next line. > >> 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. >> >> -jg > > .NET micro framework WILL run on single chip microcontroller. > http://www.ghielectronics.com/product/113 > That is what this thread is about. > > >This gets back to what is an embedded system. I am sure M$ has its sights on iPhones and the like, not real embedded systems like motor drives and instrumentation. In the 80s, the Z80 and 8086 covered the landscape with embedded system hidden for public view to the TRS-80 Business machine. As each generation of new processors hit the market, business application gets more CPU power to run. Once the internet hit, there was not ever enough CPU and Graphics horsepower. I for one have seen M$ steal the term "embedded" to mean something that I have never worked with. I like many (most) here, work in the real embedded world. Having a 32-bit processor is really nice when algorithms get very complicated. But resource limited (read cost limited) processors are whats in the embedded world. So, if the OP wants to build a new app for the iPhone or whatever, he is just building a high level app like what a CPM/PC/MAC has been doing for years, not doing real embedded work. don
Reply by ●December 11, 20092009-12-11
nospam wrote:> David Brown <david.brown@hesbynett.removethisbit.no> wrote: > >>> EC++ never made it to mainstream. >> EC++ is just C++ with some bits missing. The theory was it would avoid >> the "bloat" - in practice, it avoids some of the more useful features >> that would improve development with no run-time or code space costs. > > The theory was suppliers could keep selling obsolete C++ compilers by > coming up with a new name. >I hadn't thought of that, but it does make a sort of sense. While you can argue that omitting all support for exceptions and rtti saves runtime costs, omitting template support saves nothing (it only costs if you use templates badly) - but many earlier C++ compilers had poor or missing template support. However, without further evidence I'll have to assume EC++ was conceived with the best of intentions, and simply botched.
Reply by ●December 11, 20092009-12-11
Andrew wrote:> larwe wrote: >> On Dec 10, 10:34 am, Andrew <asm...@blackstone.biz> wrote: >> >>> That appears to be microsoft's purpose in promoting micro framework. >>> >> >> No, the purpose in promoting micro framework is to establish a >> beachhead in a market where Microsoft has never been successful, with >> a proprietary programming language controlled by Microsoft, and >> thereby to steer larger projects towards laughably unpopular operating >> systems such as WinCE. >> >> You really are a troll. > > Uh, you are quoting something I didn't write and attaching my name. >It's not much of a quotation, but you did in fact write the quoted line.> As for being a "troll", just because you > find a topic disturbing, doesn't mean others > don't find it interesting.A "troll" is someone who deliberately makes provocative statements or questions designed mainly to irritate people. I don't believe you are "trolling", but I can certainly see why some here view you as such. The simple fact is that MS in general, and dotnet in particular (micro or not) is so far out of line with /real/ embedded development that many experienced engineers here will think you are either a troll, an astroturfer (someone who, for their own financial gain, pretends to be genuinely enthusiastic about a product), or you are simply ignorant and inexperienced in the field of embedded development, and have been duped by marketing. Given your email address, it would be easy to think that you are an astroturfer - you are trying to drum up support and enthusiasm for this framework or products using it, presumably because Blackstone has invested in companies promoting it. The flaw in this theory is that astroturfers seldom use a valid email address. Of course, it is also conceivable that this micro framework is useful for some applications and some developers. I can't deny having a certain prejudice against anything with "Microsoft" and "embedded" in the same sentence (though I use Windows on desktops for pragmatic reasons) - MS has build up a very clear reputation over many years that I believe justifies this prejudice. Nonetheless, the topic is interesting, and the thread would be rather boring without someone who thinks the framework has its merits!
Reply by ●December 11, 20092009-12-11
On Dec 10, 11:54=A0pm, Andrew <asm...@blackstone.biz> wrote:> larwe wrote: > > On Dec 10, 10:34 am, Andrew <asm...@blackstone.biz> wrote: > > >> That appears to be microsoft's purpose in promoting micro framework. > > Uh, you are quoting something I didn't write and attaching my name.NOT true. Look at the thread. You added the line "That appears to be..."
Reply by ●December 11, 20092009-12-11
On 2009-12-10, David Brown <david.brown@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@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world
Reply by ●December 11, 20092009-12-11
Simon Clubley wrote:> On 2009-12-10, David Brown <david.brown@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. >
Reply by ●December 11, 20092009-12-11
On Fri, 11 Dec 2009 14:23:32 +0100, David Brown <david@westcontrol.removethisbit.com> wrote:>Simon Clubley wrote: >> On 2009-12-10, David Brown <david.brown@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
Reply by ●December 11, 20092009-12-11
In article <ecd41288-7b2b-4ebf-a4a8- f68651810ddd@w19g2000pre.googlegroups.com>, jim.granville@gmail.com=20 says...> On Dec 11, 4:34=A0am, Andrew <asm...@blackstone.biz> wrote: > > > > I'm a developer. Just lost a project that could have been > > done with an AVR to ARM with micro framework. >=20 > What was the project, and what volumes, and future-change targets ? >=20 > Quite a few low volume applications, have a wide range > of possible solution candidates. >=20 > > > > That is the topic of this thread. > > Are cheap 32bit micros going to displace 8bit micros? > > The cost difference is converging. >=20 > Not quite, The thread topic seems to confuse Microprocessor, with > Microcontroller. >=20 > Most high volume embedded designs, use Microcontrollers : Single chip > devices, with fixed Code and Ram. > The software also tends to be fixed. >=20 > 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. >=20 > Sure. the latter category ARE getting physically smaller, but they > will NEVER display Microcontrollers. >=20Ummm---- 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
Reply by ●December 11, 20092009-12-11
On Dec 11, 8:23 am, David Brown <da...@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