Microsoft .net micro framework
Microsoft .net micro framework
Hej!
Är det någon som har testat kort som kör på Microsofts plattform .net micro framework?
Är det någon som skulle vara intresserad av att testa, om jag kunde ordna fram ett kort?
Här finns lite info -- kolla också länkarna i slutet av texten:
http://www.etn.se/index.php?option=com_ ... Itemid=126
-- Jan Tångring, Elektroniktdiningen (www.etn.se)
Är det någon som har testat kort som kör på Microsofts plattform .net micro framework?
Är det någon som skulle vara intresserad av att testa, om jag kunde ordna fram ett kort?
Här finns lite info -- kolla också länkarna i slutet av texten:
http://www.etn.se/index.php?option=com_ ... Itemid=126
-- Jan Tångring, Elektroniktdiningen (www.etn.se)
Problemet ligger ju också i att man då ska införskaffa denna förhatliga .NET-kompilern (licenskostnad typ), jag är faktisk vara sugen på att testa hursomhelst men jag hinner helt enkelt inte, jag är inte riktigt på 100% än med tanke på senaste tidens händelser.
Men vad vill du ha testat?
Är det bara att modulen fungerar eller ska det vara en tyngre applikation.
Jag har rakt av ett projekt jag kan testa den på men sedan var det tiden & licensen....
Men vad vill du ha testat?
Är det bara att modulen fungerar eller ska det vara en tyngre applikation.
Jag har rakt av ett projekt jag kan testa den på men sedan var det tiden & licensen....
Jag vill bara veta hur det känns att utveckla mot den. Jag har inte kompetens att testa själv.
Licenser och sådant förutsätter jag att leverantören fixar, annars blåser vi av det.
Det här är alltså för ett test, i vår tidning, för att berätta för våra läsare hur det känns att jobba mot plattformen.
Ju utförligare test, desto bättre, naturligtvis. Testa robustheten, enkelheten att utveckla drivrutiner, utvecklingsmiljön, strömsnålheten, allt det som de skryter om.
Jag skrev en ny artikel idag:
http://www.etn.se/index.php?option=com_ ... &Itemid=70
Licenser och sådant förutsätter jag att leverantören fixar, annars blåser vi av det.
Det här är alltså för ett test, i vår tidning, för att berätta för våra läsare hur det känns att jobba mot plattformen.
Ju utförligare test, desto bättre, naturligtvis. Testa robustheten, enkelheten att utveckla drivrutiner, utvecklingsmiljön, strömsnålheten, allt det som de skryter om.
Jag skrev en ny artikel idag:
http://www.etn.se/index.php?option=com_ ... &Itemid=70
jan>>>
Har svårt att se .Net snurra på en 28MHz ARM7, jag blev verkligen besviken på .Net Compact (.Net Mobile) när jag testade den på en ARM11 (400MHz XScale) med 64 MB RAM.
Jag föreslår att du skaffar ett likvärdigt ucLinux kort och jämför pris/prestanda head-to-head.
Något alla verkar ha missat här är att MS är ute efter det marknadsegment där hårdvaran ännu inte klarar av att köra ucLinux. Det kommer nog att bli en ändring där snart, nu när man kan få en ARM för under en Dollar. Och detta gillar inte Microsoft.
Dom vill också låsa utvecklarna till Microsofts egna utvecklingsmiljö så att folk inte byter till Linux när system växer.
-ucadv
PS. Har du lite mer info om utvecklingskortet?
Har svårt att se .Net snurra på en 28MHz ARM7, jag blev verkligen besviken på .Net Compact (.Net Mobile) när jag testade den på en ARM11 (400MHz XScale) med 64 MB RAM.
Jag föreslår att du skaffar ett likvärdigt ucLinux kort och jämför pris/prestanda head-to-head.
Något alla verkar ha missat här är att MS är ute efter det marknadsegment där hårdvaran ännu inte klarar av att köra ucLinux. Det kommer nog att bli en ändring där snart, nu när man kan få en ARM för under en Dollar. Och detta gillar inte Microsoft.
Dom vill också låsa utvecklarna till Microsofts egna utvecklingsmiljö så att folk inte byter till Linux när system växer.
-ucadv
PS. Har du lite mer info om utvecklingskortet?
De utvecklingskort som jag känner till är
Freescale i.MXS:
http://www.embeddedfusion.com/default.aspx?id=64
http://www.freescale.com/webapp/sps/sit ... 17297301A5
Diverse Digi-moduler (Arm7):
http://www.digi.com/dotnet/
Rhode consulting, hittar ingen länk: "the FlexiDis Evaluation Kit ... Atmel ARM7 and ARM9 ... with speeds of up to 180 MHz ... up to 16 MB of flash and SDRAM ... 2.2-inch QVGA display"
Microsofts egen Micro Frameworksajt:
http://msdn2.microsoft.com/en-us/embedded/bb267253.aspx
port513 nämnde en SC (starcore?) -- den hittar jag inte
Freescale i.MXS:
http://www.embeddedfusion.com/default.aspx?id=64
http://www.freescale.com/webapp/sps/sit ... 17297301A5
Diverse Digi-moduler (Arm7):
http://www.digi.com/dotnet/
Rhode consulting, hittar ingen länk: "the FlexiDis Evaluation Kit ... Atmel ARM7 and ARM9 ... with speeds of up to 180 MHz ... up to 16 MB of flash and SDRAM ... 2.2-inch QVGA display"
Microsofts egen Micro Frameworksajt:
http://msdn2.microsoft.com/en-us/embedded/bb267253.aspx
port513 nämnde en SC (starcore?) -- den hittar jag inte
Jag ska se om jag kan testa deras SDK nästa vecka. den innehåller tydligen även en emulator 
Ett av företagen säljer identisk hårdvara med Linux & WxWorks. Kunde vara kul att mäta footprint, interrupt latency och prestanda på alla tre systemen?
fast jag vet inte... det kanska är Java system (läs: symbian + MIDP 2) man ska jämföra den här grejen med? eller kanske det är eCos, MicroC/OS-II, L4 och FreeRTOS den tävlar med?

Ett av företagen säljer identisk hårdvara med Linux & WxWorks. Kunde vara kul att mäta footprint, interrupt latency och prestanda på alla tre systemen?
fast jag vet inte... det kanska är Java system (läs: symbian + MIDP 2) man ska jämföra den här grejen med? eller kanske det är eCos, MicroC/OS-II, L4 och FreeRTOS den tävlar med?
Det här skulle jag gärna vilja ha forumets åsikt om -- vad kan man egentligen jämföra Dotnet Micro Framework med?ucadv skrev:... det kanska är Java system (läs: symbian + MIDP 2) man ska jämföra den här grejen med? eller kanske det är eCos, MicroC/OS-II, L4 och FreeRTOS den tävlar med?
Jag tycker det känns nästan unikt att kunna jobba på en såpass hög abstraktionsnivå mot så små system.
Men jag vet inte -- är det det?
Finns det andra experiment med skriptspråk eller dylikt för att programmera system i den här storleken?
Det enda exempel jag kan komma på, på något som möjligen ligger på en ännu högre nivå, är att jobba med Labviews inbyggnadsverktyg, med kodgenerering från deras diagramspråk:
http://www.ni.com/labview/embedded_dev_module.htm
Min fråga är alltså: vad finns det för högnivåspråkalternativ för den som vill jobba mot små ionbyggnadskort? Eller är det bara maskinnära C eller assembler som gäller?
Fördelen vid ett högt abstraktionsnivå är ju att det blir snabbare att åstadkomma resultat och utföra avancerade funktioner.
Nackdelen är att ju högre nivå man programmera på, ju mer datorkraft "spillas" utan att göra egentligen nytta.
Jag har svårt att se att en ARM7 på 28MHz har MIPS nog att ge hygglig prestanda på detta nivå, för mig vore det mer vettigt att hålla mig till C(++), kanske med tillgång till trimmad TCP-IP-stack och vad som är specifikt för kortets funktioner, det ville ge svarstider och prestanda man inte ska skämmas för.
Om det är en 8, 16 eller 32 bitars processor man kör har väl mindre betydelse när en hel del av processortiden går med att kolla bytes, flytta buffrar osv, fler bitar har ju större betydelse när man ska räkna och en PIC/AVR kan ju lätt tugga 20MHz, skillnaden upp till 28MHz är inte så stor att det känns befogad med ett så högt abstraktionsnivå på programmeringen.
Man kan tveklöst åstadkomma bra funktioner i .NET med detta modul men detta kan man sannolikt uppnå lika enkelt med C(++) och jag tror att det blir lättare att debugga ju lägre nivå man befinner sig på.
Nackdelen är att ju högre nivå man programmera på, ju mer datorkraft "spillas" utan att göra egentligen nytta.
Jag har svårt att se att en ARM7 på 28MHz har MIPS nog att ge hygglig prestanda på detta nivå, för mig vore det mer vettigt att hålla mig till C(++), kanske med tillgång till trimmad TCP-IP-stack och vad som är specifikt för kortets funktioner, det ville ge svarstider och prestanda man inte ska skämmas för.
Om det är en 8, 16 eller 32 bitars processor man kör har väl mindre betydelse när en hel del av processortiden går med att kolla bytes, flytta buffrar osv, fler bitar har ju större betydelse när man ska räkna och en PIC/AVR kan ju lätt tugga 20MHz, skillnaden upp till 28MHz är inte så stor att det känns befogad med ett så högt abstraktionsnivå på programmeringen.
Man kan tveklöst åstadkomma bra funktioner i .NET med detta modul men detta kan man sannolikt uppnå lika enkelt med C(++) och jag tror att det blir lättare att debugga ju lägre nivå man befinner sig på.
Okej, nu har jag hunnit leka lite med den.
Upplägget liknar Compact Framework. Man kompilerar koden för antingen en emulator eller en "target". Men både emulatorn och målsystemet är CLR baserade, så det är egentligen ingen större skillnad mellan dom. Det som saknas är mer eller mindre hela .Net Framework (.NET biblioteket alltså). Och visst, har man jobbat med "dotnet" på PC så känner man igen sig - på gott och ont
Även om den har hunnit växa till version 2.0 så känns det hela väldigt mycket "beta". Det är rätt mycket som inte fungerar. Om jag ska vara ärlig så verkar det som om nån ingenjör/praktikant/sommarjobbare på Microsoft försökt köra Compact Framework på en liten CPU, tagit bort _allt_ som har med .NET att göra i ett desparat försök att få in den och kallat sedan resultatet för "Mico Framework". Det hela liknar just nu mer en "technology demo" än en product.
Det mesta av det som finns idag finns under två bibliotek, en för emulering och en för "hård" exekvering (under Microsoft.SPOT.Hardware). Den sistnämnda innehåller egentligen inte mycket mer är interface för GPIO, I2C, SPI lite och annat.
Jag har inte lyckats få Micro att fungera på mina utvecklingskort än.
Upplägget liknar Compact Framework. Man kompilerar koden för antingen en emulator eller en "target". Men både emulatorn och målsystemet är CLR baserade, så det är egentligen ingen större skillnad mellan dom. Det som saknas är mer eller mindre hela .Net Framework (.NET biblioteket alltså). Och visst, har man jobbat med "dotnet" på PC så känner man igen sig - på gott och ont

Även om den har hunnit växa till version 2.0 så känns det hela väldigt mycket "beta". Det är rätt mycket som inte fungerar. Om jag ska vara ärlig så verkar det som om nån ingenjör/praktikant/sommarjobbare på Microsoft försökt köra Compact Framework på en liten CPU, tagit bort _allt_ som har med .NET att göra i ett desparat försök att få in den och kallat sedan resultatet för "Mico Framework". Det hela liknar just nu mer en "technology demo" än en product.
Det mesta av det som finns idag finns under två bibliotek, en för emulering och en för "hård" exekvering (under Microsoft.SPOT.Hardware). Den sistnämnda innehåller egentligen inte mycket mer är interface för GPIO, I2C, SPI lite och annat.
Jag har inte lyckats få Micro att fungera på mina utvecklingskort än.