This from Microsoft

http://www.eetimes.com/news/design/showArticle.jhtml;jsessionid=AABMPQBOIUMWGQSNDLOSKHSCJUNN2JVN?articleID=197005873

leads to this
http://www.embeddedfusion.com/default.aspx?id=76
http://www.embeddedfusion.com/default.aspx?id=64
- claims ~35x35mm module, and says this

"The most notable aspect of the .NET Micro Framework is that it does not 
need any underlying operating system. The Micro Framework requires very 
little in the way of system resources thus reducing the overall cost of 
a system. (The minimum memory resources are about 384K of FLASH/ROM and 
256K of RAM)"

Any one used this ? - the claims of 384KF/256KR on one page and 
512KF/256KR on another, do not say what that is capable of running,
nor minimul program sizes. Speed is also not discussed.

If this downloads/runs MSIL instructions, pgms should be relatively small.

This is not that far above present single chip resource.
Flash is well past 384/512KF, on top end devices, but few devices 
currently have 256KR.
Some of this could move into ROM.

This could change the resorce targets for chip release ?

-jg

"Jim Granville" <n...@designtools.maps.co.nz> skrev i meddelandet 
news:45d35ba1$1...@clear.net.nz...
>
> This from Microsoft
>
>
http://www.eetimes.com/news/design/showArticle.jhtml;jsessionid=AABMPQBOIUMWGQSNDLOSKHSCJUNN2JVN?articleID=197005873
>
> leads to this
> http://www.embeddedfusion.com/default.aspx?id=76
> http://www.embeddedfusion.com/default.aspx?id=64
> - claims ~35x35mm module, and says this
>
> "The most notable aspect of the .NET Micro Framework is that it does not 
> need any underlying operating system. The Micro Framework requires very 
> little in the way of system resources thus reducing the overall cost of a 
> system. (The minimum memory resources are about 384K of FLASH/ROM and 256K 
> of RAM)"
>
> Any one used this ? - the claims of 384KF/256KR on one page and 
> 512KF/256KR on another, do not say what that is capable of running,
> nor minimul program sizes. Speed is also not discussed.
>

Since this is MS first attempt at an RTOS for non-MMU machines,
my guess is that the 256 kB will provide you with a simple round-robin
scheduler (no preemptive multitasking) and non-nestable interrupts.
If you want to add any actual applications, then memory needs will grow  ;-)


> If this downloads/runs MSIL instructions, pgms should be relatively small.
>
> This is not that far above present single chip resource.
> Flash is well past 384/512KF, on top end devices, but few devices 
> currently have 256KR.
> Some of this could move into ROM.
>
> This could change the resorce targets for chip release ?
>
> -jg
>
>


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

Ulf Samuelsson <u...@a-t-m-e-l.com> wrote:
> Since this is MS first attempt at an RTOS for non-MMU machines,

There is nothing realtime about the .NET Mircro Framework their FAQ even
states.

"Given the high clock speeds of the underlying hardware the lack of
real time support is not a major problem." 

You have to write in C# as far as I can tell, other languages targeting the
CLR are not supported. Download and debug is over serial ports not JTAG.

Accorind to this: 

http://www.infoq.com/news/2007/02/.NET-Micro

It doesn't support JITing, it's not clear if it even executes CLR byte code,
the link could be taken either way. It does appear to allow you to write
native methods though.

You have to have Visual Studio 2005 to use it.

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------

Paul Gotch wrote:
> Ulf Samuelsson <u...@a-t-m-e-l.com> wrote:
> 
>> Since this is MS first attempt at an RTOS for non-MMU machines,
> 
> There is nothing realtime about the .NET Mircro Framework their
> FAQ even states.
> 
> "Given the high clock speeds of the underlying hardware the lack
> of real time support is not a major problem."
> 
> You have to write in C# as far as I can tell, other languages
> targeting the CLR are not supported. Download and debug is over
> serial ports not JTAG.
> 
> Accorind to this:   http://www.infoq.com/news/2007/02/.NET-Micro
> 
> It doesn't support JITing, it's not clear if it even executes
> CLR byte code, the link could be taken either way. It does
> appear to allow you to write native methods though.
> 
> You have to have Visual Studio 2005 to use it.

No RT, C#, VS, MS.  With all those strikes against it, why should
anyone ever consider using it?  You know that anything from MS is
buggy, and will not be supported.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>;
 <http://www.securityfocus.com/columnists/423>;
 
 "A man who is right every time is not likely to do very much."
                           -- Francis Crick, co-discover of DNA
 "There is nothing more amazing than stupidity in action."
                                             -- Thomas Matthews

On Feb 14, 8:55 pm, CBFalconer <cbfalco...@yahoo.com> wrote:

> No RT, C#, VS, MS.  With all those strikes against it, why should
> anyone ever consider using it?  You know that anything from MS is
> buggy, and will not be supported.

Microsoft's support of .NET has been extremely thorough. They have
gone far beyond anyone's expectations, and they even have regional
support centers where they offer free assistance to developers. I've
rattled their cage on more than one occasion.

They took to heart all of the criticism they got up through the 80's
and 90's, and the company turned around in 2001. They're now far more
open, and they're well connected with developers. Microsoft employees
are also active in the newsgroups.

It remains to be see if they understand MCUs, but this looks positive
to me.

Eric

Jim Granville <n...@designtools.maps.co.nz> writes:
> 
> This from Microsoft
> 
> http://www.eetimes.com/news/design/showArticle.jhtml;
> jsessionid=AABMPQBOIUMWGQSNDLOSKHSCJUNN2JVN?articleID=197005873
> 
> leads to this
> http://www.embeddedfusion.com/default.aspx?id=76
> http://www.embeddedfusion.com/default.aspx?id=64
> - claims ~35x35mm module, and says this
> 
> "The most notable aspect of the .NET Micro Framework is that it does not 
> need any underlying operating system. The Micro Framework requires very 
> little in the way of system resources thus reducing the overall cost of 
> a system. (The minimum memory resources are about 384K of FLASH/ROM and 
> 256K of RAM)"

384K (or 512K) ROM and 256K RAM is "very little in the way
of system resources"?!?  Compared to what?

> Any one used this ? - the claims of 384KF/256KR on one page and 
> 512KF/256KR on another, do not say what that is capable of running,
> nor minimul program sizes. Speed is also not discussed.
> 
> If this downloads/runs MSIL instructions, pgms should be
> relatively small.

They'll have to be small to be shoehorned into the machine
after M$ has usurped all the resources.

> This is not that far above present single chip resource.
> Flash is well past 384/512KF, on top end devices, but few devices 
> currently have 256KR.  Some of this could move into ROM.
> 
> This could change the resorce targets for chip release ?

On Feb 14, 6:39 pm, Paul Gotch <p...@at-cantab-dot.net> wrote:

> Accorind to this:
> http://www.infoq.com/news/2007/02/.NET-Micro
>
> It doesn't support JITing, it's not clear if it even executes CLR byte code,
> the link could be taken either way. It does appear to allow you to write
> native methods though.

They way I understand it, they have a new kind of IL that was designed
to be interpreted. It reminds me of the DotGNU project: they translate
IL into a new dialect of IL that is more friendly to interpretation,
and they have a runtime interpreter to run that. The "full" IL for
PC's lacks the kind of type information you'd need to execute it
quickly with an interpreter (the JIT compiler gets the type info from
various metadata). For example, the IL instruction to add 2 values
doesn't specify the size of the operands (unlike Java's JVM
bytecodes).

> You have to have Visual Studio 2005 to use it.

Yes, I'm guessing the free Express version won't work with it. I
believe that is also the case for the CE platform. However, you
probably only need VS for debugging, or for rich designtime
functionality. Microsoft normally allows people to develop apps with
Notepad, or third-party tools. It comes down to a question of
deployment, and I am guessing that can also be done outside of VS
since they are just using a serial port.

By the way, their serial port support in CE is quite good, so I expect
the same here. It shouldn't have the slow klunky feeling that Arm's
Angel monitor had when debugging over a serial port. It should be
pretty responsive. If it's not responsive it will quickly die in the
developer marketplace.

Eric

On Feb 14, 1:59 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> This from Microsoft
>
> http://www.eetimes.com/news/design/showArticle.jhtml;jsessionid=AABMP...
>
> leads to this
> http://www.embeddedfusion.com/default.aspx?id=76
> http://www.embeddedfusion.com/default.aspx?id=64

This looks like a low cost dev board for the Micro Framework. This
runs at 200 Mhz and has 2, USB host mode interfaces, and an Ethernet
port. It can also run linux. It doesn't have an LCD, but this looks
like a steal for the money.

http://www.emacinc.com/sbc_microcontrollers/ipac_9302.htm

Freescale also has a dev kit, and it also has an LCD - is this the
same as the one from Embedded Fusion? Note that the USB is only 1.1
and it's not a host interface. I don't know if they have a linux
option, but Freescale is linux-friendly with some of their other
boards. It runs only at 100 Mhz. Sadly, this does not use the new
Cortex A8 that Freescale is supposed to be working on.

http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=02XPgQ8217297301A5

Eric

Eric wrote:
> On Feb 14, 8:55 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> 
>> No RT, C#, VS, MS.  With all those strikes against it, why should
>> anyone ever consider using it?  You know that anything from MS is
>> buggy, and will not be supported.
> 
> Microsoft's support of .NET has been extremely thorough. They have
> gone far beyond anyone's expectations, and they even have regional
> support centers where they offer free assistance to developers. I've
> rattled their cage on more than one occasion.

C# by itself is a turn-off.  It does not have an ISO standard.  MS
drops more things than my cat has kittens.

-- 
 If you want to post a followup via groups.google.com, ensure 
 you quote enough for the article to make sense. Google is only
 an interface to Usenet; it's not Usenet itself. Don't assume
 your readers can, or ever will, see any previous articles.
More details at: <http://cfaj.freeshell.org/google/>;

Eric <e...@yahoo.com> wrote:
> Yes, I'm guessing the free Express version won't work with it.

Standard Edition required.

> I believe that is also the case for the CE platform.

I think they've unified it so you just now need VS 2005 and don't need VS
Embedded which was in effect a previous version of VS retargetted.

I think there is still a separate kernel debugger though.

> Notepad, or third-party tools. It comes down to a question of
> deployment, and I am guessing that can also be done outside of VS
> since they are just using a serial port.

Depends if the they've docmented the protocol spoken to the monitor, MS are
notorious for keeping such things closed so they can change them.

> the same here. It shouldn't have the slow klunky feeling that ARM's
> Angel monitor had when debugging over a serial port.

Angel was written back in the days of 9600 Kbaud serial ports, it had been
superceeded by JTAG based debugging by the time there was any need to make
it go faster or hide the latency of the serial port.

To me this seems to be a "because we can product" though. To make it go
anywhere they need a huge library of support libraries supporting the
facilities available on common microcontrollers and they need to add JTAG
debugging.

Otherwise it doesn't really provide anything you can't do with existing C
based toolkits from incumbant vendors and it requires oodles more RAM and
faster processors.

Another point is that with the C based tool kits you at least have the
illusion of being able to change tools providers even if in practice it's
very hard, the .NET stuff is essentially single source single toolchain.

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------