.NET micro framework ... end of embedded world???

On Dec 10, 10:34=A0am, 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.

On Dec 10, 5:40=A0pm, Andrew <asm...@blackstone.biz> wrote:
> ....
> C++ flopped for embedded. EC++ never made it to mainstream.
> C remains the staple for small firmware projects.
>
> Its remained that way for 30 years. Seems like change is inevitable.
> But when and what? If the cost is the same for 8bit vs. 32bit
> then its logical that something else is possible in the
> not so distant future.
>
> The question is will it be something like C# micro framework?

It may well be that embedded goes down the drain like PCs did
decades ago (being Intel & MS based makes them useless to me
except for TV-set like usage).

But I am not sure MS are there yet. How large a memory footprint
will something based on that stuff have? If cost does not matter,
power consumption will likely continue to do so - and larger
code size means not only more memory to be kept powered, but
more memory accesses, each costing power. Same goes for the wider bus.

For example, recently I introduced this: http://tgi-sci.com/tgi/nmcatb.htm
.
Being remotely accessible via RFB (at 100 MbpS this is seamless, at 10
it is OK to work with); complete DPS plus the complete nuclear
spectrometry software fit in < 2 megabytes of flash, *non-compressed*
(mostly in a disk-like image, about 64K of "bios" code).
And I have not even begun to optimize for code size (have a reserve
for
old, 68-k targeted code, which could buy me another 25 to 50% - not
sure
about the exact figure).
How does that MS thing compare to these figures? (I don't know the
answer,
may be they can beat me...).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/ade=
e2974c2364dee?dmode=3Dsource

On Thu, 10 Dec 2009 10:12:17 +0100, David Brown wrote:

> As for Vladimir's comments, I guess like the rest of us he worries about 
> Windows-trained PC programmers getting involved in embedded development. 

I'm also worried about that. And by "worried", I mean "scared". A lot of
embedded development is in contexts where mistakes can kill people.

The problem isn't necessarily with the tools per se, but with the
"culture" which surrounds them.

PC development (and I include Windows, Linux, and Mac here) has a culture
where deadlines take priority and any bugs are dealt with by an endless
stream of patches. Embedded development doesn't work that way.

On Dec 10, 7:45=A0pm, Nobody <nob...@nowhere.com> wrote:
> On Thu, 10 Dec 2009 10:12:17 +0100, David Brown wrote:
> > As for Vladimir's comments, I guess like the rest of us he worries abou=
t
> > Windows-trained PC programmers getting involved in embedded development=
.
>
> I'm also worried about that. And by "worried", I mean "scared". A lot of
> embedded development is in contexts where mistakes can kill people.
>
> The problem isn't necessarily with the tools per se, but with the
> "culture" which surrounds them.
>
> PC development (and I include Windows, Linux, and Mac here) has a culture
> where deadlines take priority and any bugs are dealt with by an endless
> stream of patches. Embedded development doesn't work that way.

I believe you are understating how messy the PC development is from a
software point of view. It is a whole culture (or rather lack thereof)
of wasting resources, sometimes deliberately (to have new hardware
sold).
A PC is no more efficient than a 4 seat car sized as an apartment
block
on thousands of differently sized, awkwardly coupled and mostly
synchronized wheels.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

On Dec 10, 10:12=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> Andrew wrote:
>
> *** Interesting stuff removed ****
>

I don't think the OP will find many people supporting embedded .NET.
Not here anyway.
I am by heart a linux user, and also a windows user when forced to.
Microsoft has earned a bad reputation among many 'expert' users. I
think people shouldn't underestimate the achievements of microsoft in
the later years. A good part of the problems with different Windows
versions are not Microsoft fault, but often third party problems.
Microsoft is (arguably) responsible of a great part of current state
of computers. (for good and...)

But then, there is linux that does the same, if not much better. A
whole different philosophy.

In recent years the whole software industry has lost north. New
software
is full of useless characteristics, full of bugs etc.
Embedded is (and should be) a completely different scene. No bugs
allowed. No patching. No updating. Well, more or less.
As for the future, everything is possible. While high level languages
are interesting and possible, so is lower lever. FPGAs, soft CPUS etc.

I share the fear/concern regarding new people entering the field. I am
also concerned with management who can't tell the differences between
simple and complex developments. I fear managers that buy the idea of
simplicity. But then, they should be more concerned than me.

Regards

Josep Duran

Andrew wrote:
> Bob wrote:
>> On 9 Dec, 15:11, Andrew <asm...@blackstone.biz> wrote:
>>> What is he future? ARMs are coming down in price.
>>> Microsoft has made micro framework license free.
>>> Creating firmware has become high level (C#),
>>> cheap, and perhaps the next big thing?
>>
>> "There is no magic bullet". But marketing will always tell you they
>> have one. In high volume applications, the unit cost is the most
>> important factor, so the development environment may not even be
>> relevant. ARMs have always been coming down in price, and we have been
>> using high-level language for years, so don't expect a revolution from
>> a language which is worse in terms of embedded performance. Opening up
>> development to script kiddies is unlikely to benefit the industry
>> significantly.
>>
>>> Will asm/C go the way of the dinosaur?
>>> Will 8 bit micros become obsolete?
>>
>> Unlikely. The more likely scenario is that they will continue to
>> dominate in particular niches, and unit cost will always be an issue.
>> New higher power platforms tend to create new niches, where 8 bitters
>> were never used, eg. set top boxes.
>>
>> You really need to understand the current market place before
>> speculating about the future.  Do some research into current embedded
>> projects broken down by language and architecture. The results may
>> surprise you. Many years after C++, C still dominates, and more 8-
>> bitters are sold than ever before.
> 
> C++ flopped for embedded.

C++ is probably the second most popular language for embedded 
development these days.  I don't know the statistics, but I'd guess it 
to be more popular than assembly or java.

C++ has a reputation for adding bloat (in size and runtime) compared to 
C, especially for small systems.  That can certainly be true if you 
don't know what you are doing, and don't understand how your compiler 
works (this is typical for programmers with a PC programming 
background).  If you use decent tools and understand how they work, you 
can write C++ code for 8-bit micros with very little overhead.

So while C++ is an underdog compared to C in embedded projects, it is 
far from "flopped".

> 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.  So 
most people who might have been interested in EC++ simply use C++ 
compilers with flags like "-fno-rtti" and "-fno-exceptions", and avoid 
the STL.

> C remains the staple for small firmware projects.
> 

Correct.

> Its remained that way for 30 years. Seems like change is inevitable.

Your logic is somewhat twisted.  If it were correct that C had been the 
staple for 30 years (it hasn't - assembly used to be much more common, 
although C was used with bigger devices and bigger projects), then it 
would seem to me that a /continued dominance/ of C is inevitable.  A 
long-term constant is not exactly a typical sign of an impending change!

In fact, given the rate at which new processors and architectures come 
and go in the embedded world, the dominance of C is an outstanding 
consistency.

> But when and what? If the cost is the same for 8bit vs. 32bit
> then its logical that something else is possible in the
> not so distant future.
> 

First, the cost of 8-bit micros and 32-bit micros is /not/ the same, nor 
will it ever be.  The processor is just one of the features of a 
microcontroller, and one that many developers consider a minor point 
(mainly due to the fact that you can program them all in the same 
language - C).  You might be able to get a 32-bit micro for the same 
price as some 8-bit micros - but the feature set, including things like 
voltage ranges, power consumption, ease of use - will be different.  The 
embedded development community likes a wide choice, and it likes a 
consistency of devices across projects - 8-bit micros will remain 
popular for a long time even if they were more expensive.

> The question is will it be something like C# micro framework?

The answer is no.  Even though the micro framework has an Apache 
license, few people that are not already committed MS fanboys would 
trust anything from them - even if there were any technical reasons to 
choose it.

Andrew wrote:
> David Brown wrote:
>> Andrew wrote:
>>> Vladimir Vassilevsky wrote:
>>>>
>>>>
>>>> Andrew wrote:
>>>>
>>>>> What is he future? ARMs are coming down in price.
>>>>> Microsoft has made micro framework license free.
>>>>> Creating firmware has become high level (C#),
>>>>> cheap, and perhaps the next big thing?
>>>>>
>>>>> Will asm/C go the way of the dinosaur?
>>>>> Will 8 bit micros become obsolete?
>>>>
>>>> The future is there is going to be more and more idiots like you.
>>>
>>> Jackass.
>>
>> While there was no need for Vladimir to be so rude, what kind of 
>> answer were you expecting?  I have no idea where you are coming from, 
>> or if you understand what embedded development actually /is/ (judging 
>> from your email address, you work for an investment company rather 
>> than a development company), but few people in this newsgroup will see 
>> your questions as anything other than a poor joke or trolling.  I'll 
>> give you some answers - mainly because it's nice to have a discussion 
>> about the future, and I'd be interested to hear opinions and comments 
>> from others in the group.
> 
> I'm a developer. Just lost a project that could have been
> done with an AVR to ARM with micro framework.
> 

Without knowing your project, I can't say whether it could have been 
done with an ARM and the micro framework or not.  But I would be 
surprised indeed if you lost the project because you did not use the 
micro framework.

>> MS has never made anything for /free/, as far as I know.  It offers 
>> some things with zero cost price, but the strings attached make them 
>> far from "free".  If nothing else, their "free" stuff pushes users 
>> towards their non-free stuff.  That's not necessarily a criticism - 
>> they are a company, trying to make a living.  But hearing that 
>> "Microsoft has made micro framework license free" is of any serious 
>> interest to very few people in this area.
>>
>  > ARMs are coming down in price - that's true.  There are three sorts of
>> ARM - microcontroller ARMs (programmed in C or C++), mobile phone ARMs 
>> (programmed in C, C++ or Java), and Linux ARMs (programmed in C, C++, 
>> Java, Python, Perl, bash, tcl/tk, whatever).  C# and MS do not figure 
>> on ARM.
> 
> That is what micro framework is all about.
> C# on an ARM7 or even a Cortex.
> http://www.microsoft.com/netmf/hardware/default.mspx
> 

Have you actually had a look at the information on MS's website, or on 
Wikipedia?  They are talking about Cortex A processors - not Cortex M 
microcontrollers.  Even with the ARM7 it is aimed at processors running 
at hundreds of MHz and with large memories - the minimum memory 
footprint is 300 K according to Wikipedia.  Top-range Cortex M3 devices 
run at something like 72 MHz with 512 KB flash and 64 KB ram.

There are certainly plenty of embedded systems with sufficient 
processing power to run this stuff - but the majority of embedded 
development is done with devices that are too small, without the space 
and processing power to waste on this sort of thing.

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.


>> The market share of 32-bit microcontroller is increasing over that of 
>> the 8-bit microcontrollers, but 8-bitters are far from obsolete (4-bit 
>> microcontrollers are still mass produced).  But these 32-bit micros 
>> are better seen as being like 8-bit microcontrollers with more 
>> powerful cores and development tools - they are no more related to the 
>> PC world than the 8-bitters are.
> 
> That is the topic of this thread.
> Are cheap 32bit micros going to displace 8bit micros?

In general, no.  They will get more common, and they will take over for 
some sorts of designs - but they will not replace them.

> The cost difference is converging.
> 

You mean the /costs/ are converging.  That's true to some extent - in 
particular, there is an overlap in price and features between the 
largest 8-bit devices and the smallest 32-bit devices.  But even the 
smallest and cheapest 32-bit devices can't compete with small to medium 
8-bit devices on cost, size and power, and the typical peripheral 
features for the different classes of devices are different.

Remember, just as 32-bit micros are getting smaller, cheaper, faster, 
and lower power, so are the 8-bit micros.

>> As for Vladimir's comments, I guess like the rest of us he worries 
>> about Windows-trained PC programmers getting involved in embedded 
>> development.  Embedded systems development is very different from 
>> writing Visual Basic or C# on Windows, but PHB's often fail to 
>> understand that, resulting in the wrong people working in the wrong 
>> jobs (or perhaps the right people, but with the wrong training).
> 
> That appears to be microsoft's purpose in promoting micro framework.
> 

I think another poster summed up MS's purpose fairly well...

> "The .NET Micro Framework aims to make embedded development easier, 
> faster, and less expensive by giving embedded developers access to the 
> modern technologies and tools used by desktop application developers. 
> Additionally, it allows desktop .NET developers to use their skills in 
> the embedded world, enlarging the pool of qualified embedded developers."
> http://en.wikipedia.org/wiki/.NET_Micro_Framework
> 

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. 

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.

 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.

-jg

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.

As for being a "troll", just because you
find a topic disturbing, doesn't mean others
don't find it interesting.