On 2010-01-18, Wayne Farmer <usenet@endymionsystems.com> wrote:
>
> Here's a resource from 2007 that may answer some of your questions.
> It's a 23-page white paper in .DOC format that introduces the .NET
> Micro Framework and describes its structure and components:  http://bit.ly/80gLKP

Thank you for the link. I've added it to my list of things to read.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

On Dec 11 2009, 6:52=A0am, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2009-12-10, David Brown <david.br...@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. =A0I see no reason to suspect th=
at
> > this attempt will be any different.
>
> One thing I have not seen discussed yet: What are the realtime capabiliti=
es
> 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

Here's a resource from 2007 that may answer some of your questions.
It's a 23-page white paper in .DOC format that introduces the .NET
Micro Framework and describes its structure and components:  http://bit.ly/=
80gLKP

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?
> 
> 


Althought I don't do much assembly programming anymore, aside from the 
occasional  asm("nop");   or something like that, intimate knowledge of 
assembly language is and will always be essential for debugging an 
embedded system, at least for me, for the foreseeable future.

.NET ?   I can't see using that in any embedded system that I would design.

boB

On 2009-12-11, rwaltman <r3000@warwick.net> wrote:
> 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)
>

There are various kinds of realtime, but I define them as falling into
one of two categories: "soft realtime", when it's ok to miss a goal
sometimes, and "hard realtime", when Bad Things Happen :-) when you
miss a goal.

The OP stated that C# was on it's way to making traditional environments
obsolete. In order to be able to accurately make such a statement, one of
the things he needs to be able to show is how his environment will handle
the issues associated with current environments.

So far, I've seen little evidence for the suitability of C# for hard
realtime type applications.

Although I'm a professional programmer, I'm a hobbyist when it comes to
electronics, and even as a hobbyist I have zero interest in using it as
it doesn't meet many of my requirements.

At the low end, I am doing hard realtime on AVRs and going up the scale
I'm currently using Ada and C under RTEMS on ARM boards. (There's also the
fact that I use Linux as my development environment.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

On Dec 11, 6:06=A0pm, Andrew <asm...@blackstone.biz> wrote:
> -jg wrote:
>
> I'm sure you meant microprocessor on next line.
>
> > Microcontrollers use external memory, and commonly have operating
> > systems, and even .net baggage too.

OOps, yes  - however did that happen ? :o

-jg

On Thu, 10 Dec 2009 11:02:27 -0800, Didi wrote:

>> 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.

To be fair, there are valid reasons why PC software development works the
way it does. Mostly complexity: if typical user applications were
developed using rigorous engineering, they would cost more than anyone
was willing to pay and be obsolete long before they were released.

How would you feel about paying $1000 per copy for a web browser which
never crashed but only handled HTML 1.0 and HTTP 1.0 and only ran on OS/2?

Being limited to 2K of flash and 192 bytes of RAM does wonders for keeping
complexity under control.

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

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.
>=20
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

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

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.
>