Could the .NET Micro Framework run on the prop?

Tubular

This may have been asked before - but I couldn't find it...

The .NET framework lets Visual Studio programmers write code for 32 bit micros. There is an introduction here http://www.netmf.com/WhatIsMicroFramework.aspx

The minimum typical configuration is 64kB RAM and 256kB flash.
Some tech specs and examples of other processors is here
(click here). While the Prop doesn't have those resources internally, some designs such as Ramblade or C3 might be able to load uSD->big external ram, and execute from there.

Btw I have no intention of tackling this challenge! Just throwing it out there for comment. There are certainly lots of VS programmers out there.

And... lets leave the usual Microsoft jokes aside thanks (unless geniunely original and/or witty)

Heater.

I seriously hope not.

Ale

As most propellers have a video out, and in color... it gives the possibility of enjoying BSOD with the prop !.

Tubular: With such requirements... we are out ouf (fast) luck. LMM is needed over an already slow VM... two tiers, I see it slow but maybe doable in a RAMBlade or similar. Is nit the jvm enough ? ;-)

Heater.

Given that the Prop now has a JVM and we have such things as Zog or the Spin interpreter itself I guess some brave soul could knock up a run time for .NET

Jazzed is just about to provide the Prop with 32MB external RAM and pins too spare so it's not so crazy.

The run time might eat many COGs or be done in LMM (How slow do we want it?).

I'm still not clear on the endless debates about Microsofts patents on .Net technology or licensing issues. Which makes makes me inclined to give all such things a wide berth.

I have a hard enough time trying to understand why the world needs Java let alone a remake of it.

Still this is Prop land where impossible things get done every day.

Ale

heater... you just nailed it :

.Net on the prop... How slow you want it today ? hahaha

I only think of java as cross-platform... and it is not so good at it (with graphical environments).
C is available everywhere

Heater.

As far as I can tell the primary motivation for Java was to enable one ship closed source binary code that would run on many platforms without recompilation. Let's skip all that waffle about garbage collection and such.

As such it solves a non-technical problem that is not very interesting. In an open source world it is pretty much redundant.

The cross platform idea never did work out as far as I can tell. Especially now that Google's Android is using it's own idea of Java libraries.

ericball

.NET is based on the Common Language Infrastructure, which specifies a Virtual Execution System which executes the Common Intermediate Language instruction set. (All knowledge from Wikipedia, I'm no .NET developer.) CIL (nee MSIL) is similar to Java bytecode. So if it's possible to create a JVM for the Propeller a .NET VES may be equally achievable.

The problem is usually with the existence and size of the common libraries.

Invent-O-Doc

I don't know about prop, but prop-II might be a good candidate for this. .NET has a lot going for it and could bring many new users to the prop platform.

Dr_Acula

Intriguing. I do a lot of work in .net.

I love the enthusiasm on the video http://www.microsoft.com/netmf/about/default.mspx

These are definitely 'propellerhead' people.

I'm not sure how it would port to the propeller. The website is a bit short on detail, so I tried downloading the program, and got an error "Microsoft .net framework can only be installed on computers with Visual Studio 2008-2010..."

Clearly my .net 2008 version isn't quite good enough.

I wonder if we can find out more details. What exactly does a "Hello World" compile to?

As an aside, I always pronounced C# as 'C hash'. # is hash, right? Ha, I ran that past my wife, who is a music teacher. She says that # is sharp, to quote "I tell my students, if they call it a hash, they fail!" Of course it is C sharp, what else would it be? http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29

jazzed

Propeller JVM today is based on Java 1.1 as defined for the Parallax Javelin microcontroller. The .net CIL would be more like Java2+ than Java 1.1. Java2+ is based on a bigger JVM that supports 32 bit operations and is possible to implement but would be a much tighter fit on Propeller.

I could go down the Java2+ path which could provide the foundation for developing a CIL virtual machine. I originally planned to do that, but without any interest from the user community it is an inappropriate use of my time. There are some professors interested in what I've done with Java but that's it.

Having 32MB+ of SDRAM for Propeller programs is far more interesting to me.

Cheers.
--Steve

trodoss

Dr_Acula wrote: »

The website is a bit short on detail, so I tried downloading the program, and got an error "Microsoft .net framework can only be installed on computers with Visual Studio 2008-2010..."

Clearly my .net 2008 version isn't quite good enough.

@Dr_Acula,
I was able to get it to install. I have the .Net framework 3.5 and 4.0 on the machine (I also run VS 2008 on my PC as well).

From the documentation:

The .NET Micro Framework CLR has only one thread of execution and owns all of the memory in the system. During normal operation, the CLR iterates in the interpreter loop and schedules managed threads using a round-robin algorithm, according to the priority of the threads involved. Each managed thread gets a 20-millisecond (ms) time quantum during which the runtime executes intermediate language (IL) code that belongs to the stack of the managed thread being serviced. When the managed thread goes to sleep or waits for a synchronization primitive, such as a monitor that cannot be acquired or an event that is not signaled, the CLR puts the thread in the waiting queue and tries to schedule another thread. In between scheduling managed threads, the CLR checks for any hardware events that might have been raised at the native device driver level. If an event occurred, the CLR tries to dispatch the event to the managed thread that requested it. A hardware event is associated with some kind of input/output (I/O) event, whether it be an interrupt-based GPIO event or a serial USART, USB, or I2C event.

The architecture is based on time-slicing, which is probably to be expected. It could probably fit, and you could have cogs dedicated to being "virtual peripherals." It is interpreting MSIL bytecode [Edit:] ...well, not exactly. It looks like as part of the compilation process the bytecode is passed through optimization which produces bytecode understood by the .NET MF.

Sounds like an interesting project.

trodoss

jazzed is right though that in order to support the framework you would have to support 32 bit operations.

32MB+ of SDRAM does sound great

[Edit:]
There was a C# code parser project (http://csparser.codeplex.com/) written by Robin Debreuil a while back ago. If I remember correctly, his original intent was to use information gleamed from this project to help port C# onto microcontrollers.

jmg

Interesting. The main issue with .NET, would be trying to decouple the massive bloat, into a useful common subset of workable library calls.
(ie you would have to develop and test, in a subset case, which would limit the broad usefulness.)

Maybe a 'command line' version could have some use, and there are other areas that could morph on this work.

CIL examples :
http://en.wikipedia.org/wiki/Common_Intermediate_Language

// .NET CIL example
 ldloc.0
 ldloc.1
 add
 stloc.0    // a = a + b or a += b;

I've found quite broad similarities with the CIL (reverse polish/stack in nature) and
languages like Forth, and the IL of the PLC Language IEC61131

Some background on IEC61131 is here
http://www.controleng.com/new-products/plcs-and-pacs/single-article/speaking-in-tongues-understanding-the-iec-61131-3-programming-languages/4123b0e66c.html

more detail on IL is here
http://www.3s-software.com/index.shtml?en_CoDeSys_IL

IEC61131 IL example
CAL fb_instance (
      param1 = var1,
      param2 = 45,
      param3 = (
                LD var2
                ADD var3
               ),
      param4 = var4
    )      

and there is another branch, called Structured Text (ST), which is Similar to Modula-2/Pascal/Some BASICs in nature :

http://www.3s-software.com/index.shtml?en_CoDeSys_ST

Following their links some more, I see they added TI C2000/28x CPUs, and have a free
download of the SW environment, but a licensed kernal.

blittled

There is one drawback to using the framework. Since it is managed code and there is automatic garbage collection real time handling is not guaranteed. The garbage collecting can take up to 10 milliseconds. I have the FEZ Domino from www.tinyclr.com and it runs the C# micro framework has this issue and it is stated that it should not be used for real time environments.

Tubular

Hey all. Lots of good feedback overnight. It seems remotely possible which is encouraging. Admittedly this stuff and its associated bloat is not for the purists

@jmg - I'm familiar with 61131 in its 3 forms, but didn't realise the similarities. Interesting. I'm not sure about a subset, I was thinking more along lines of big memory and support as much as practical

@blittled, the "not (usually) for real time environs" is a double sided coin. The way I see it the .netmf can execute in a cog or two, we can still do real time stuff in other cogs by working out a suitable way of encapsulating "peripherals" that actually load in a new cog and execute in real time. That could be a big advantage for the prop vs other .netmf micros.

Oldbitcollector (Jeff)

Watching the video I can really see where Microsoft is planning to go to get the "Ordinary Joe" with microcontroller technology. That's exciting stuff. On the other hand, I'm NOT excited about .NET being the vehicle to get there for all the of the reasons we already know.

BSOD on my Prop, or PropII.. NO THANK YOU.

OBC

jmg

Tubular wrote: »

@jmg - I'm familiar with 61131 in its 3 forms, but didn't realise the similarities. Interesting. I'm not sure about a subset, I was thinking more along lines of big memory and support as much as practical

Then the SDRAM support planned for Prop2, should remove one ceiling

The Prop/Prop2 would give an easy side-step for the lack of hard-real time,
For code where that matters, just dedicate a core.
Of course, it would be nice to also develop the 'tight stuff' in the same environment, to
allow some elasticity across the boundary.

That's where having a common-subset could be important.

So maybe this would need both
a) CIL => PASM
and the more usual
b) CIL => .NET Bytecode

Path a) would allow fast speed, for tasks expected to load-and-stay in on chip code memory,whilst Path b) would cover the bulk-code.
Library calls (especially maths/string libs), would need local native versions.

lonesock

What about simply (hah!) writing a CIL interpreter? There's 'only' 250 bytecodes or so. [8^)

http://en.wikipedia.org/wiki/List_of_CIL_instructions

edit: oops, missed the fact that this was mentioned already, at least twice

Jonathan

trodoss

@lonesock,
You could also "cheat" and use the 11 opcodes (Zog).

I don't know if using ZPU bytecode would be easier than convering CIL to PASM, but might be worth a try. It is a smaller instruction set than the Javelin bytecode.

--trodoss

Heater.

trodoss:

Whilst you can build a ZPU interpreter with only the basic 11 byte codes it would be very slow. The ZPU GCC compiler actually emits 50 odd different byte codes. Those extra ones would be synthesized in the interpreter by vectoring out to subroutines written in the 11 basic codes. This is slow and requires a kilo byte or so of extra code in the executable. ZOG implements, in PASM, all the ZPU byte codes used by GCC. That's the only way to get Spin like performance out of it.

I don't think you are ever going to see, or want to see, CIL to PASM. With only 512 instructions fitting in the COG it's not going to work very well for anything much.

Perhasp CIL to LMM (or even ZPU byte codes) for execution from HUB is more reasonable.

But it looks like a CIL bye code interpreter would be the way to go. Interesting that it is stack based like the ZPU.

jazzed

The CIL byte codes look almost identical to Java. A CIL interpreter would be just another virtual machine or emulator. There are many such examples these days.

Lots of common and time sensitive routines can stay in COG and the actual instruction interpreter code can be swapped in/out with very little overhead except for method calls. Performance would be about the same as Propeller JVM.

One has to decide up front if the library code is linked as a monolithic blob or swapped class files though. A single blob would be faster, but swapped files would allow bigger programs in Propeller's little memory without needing a library linker.

A large virtual disk in SDRAM could make file swap performance tolerable Support for 32MB+ SDRAM is progressing nicely now. Today, ZOG is running programs from SDRAM Soon Catalina will too.

Cheers.
--Steve