Angeregt durch diesen Thread Beitrag "Empfehlung f. ARM7 Board mit .Net Micro Framework gesucht" habe bin ich ein wenig zum Thema .NET Micro Framework (NETMF) rumgesurft. Ich habe heute zum ersten Mal davon gelesen, dass ein abgespecktes .NET schon auf relativ kleinen Systemen mit ARM7-, ARM9- und Blackfin-Prozessoren lauffähig ist. Das NETMF scheint auch schon halbwegs dem Visions-Stadium entwachsen zu sein, denn immerhin hat es MS geschafft ein paar namhafte Prozessorhersteller (NXP, Atmel und Analog Devices) ins Boot zu holen. Bis jetzt sah ich keinen Anlass, mich in .NET, C# und alles, was sonst noch dazu gehört, einzuarbeiten, da es sich dabei im Wesentlichen um eine Plattform für die Windows-Programmierung handelt, mit der ich mich kaum beschäftige. Da .NET nun aber von PCs über PDAs bis zu mittelgroßen Mikrocontrollersystemen herunterskalierbar zu sein scheint und auch die Anzahl der unterstützten Prozessortypen wächst, bin ich am Überlegen, ob nicht vielleicht das die zukünftige Form der Softwareentwicklung sein wird, an der sich jeder Entwickler orientieren wird. Entweder freiwillig, weil er wirkliche Vorteile davon hat oder gezwungenermaßen, weil irgendwelche Was-Zu-Sagen-Haber dieses System zum De-Facto-Standard erheben. Mich würde einfach mal eure Meinung dazu interessieren, sowohl die der Windows-Anwendungsentwickler, die schon längere Zeit mit .NET arbeiten als die der hardwarenahen Softwareentwickler, die Erfahrung mit den besagten Zielprozessoren (ARM und Blackfin) haben. Und natürlich erst recht die von denen, die in beiden Welten zu Hause sind. Noch etwas vorab: Ich mache keinen Hehl daraus, dass ich Windows toll wie Hämorrhoiden finde. Da sich jedoch .NET in Form des NETMF, zumindest was das Zielsystem betrifft, vollständig von den Windows-Betriebssystemen (PC-Versionen und auch CE) gelöst hat, würde es mich trotzdem freuen, wenn die Diskussion halbwegs beim Thema bliebe und nicht ein weiterer Gegenfensterflammenkrieg ausbricht.
Ich zähle mich eher zur Gruppe der Steuerungsentwickler und mache hiermit mal einen Anfang mit ein paar Aspekten, Fragen und offenen Punkten, die während meiner NETMF-Surferei aufgepoppt sind, und die mich im Moment noch davon abhalten, gleich morgen alle meine Entwicklungsarbeiten auf NETMF umzustellen: Irgendwie hat sich mir der Sinn des Ganzen (noch) nicht so ganz erschlossen, was aber damit zusammenhängen kann, dass ich .NET nur aus einigen Zeitschriften- und Internetartikeln kenne. Auf den Übersichtsseiten von Microsoft erfährt man ziemlich wenig über die technischen Vorzüge dieses Frameworks. Da werden neben dem üblichen Marketing-Gerassel (Time-to-Market, Efficiency, Reliability usw.) als wesentliche Vorteile herausgestellt, dass man mit Visual Studio entwickeln und in C# programmieren kann. Ok, das erleichtert sicher einigen Windows-Programmierern den Einstieg in die Mikrocontroller- welt. Aber welche Vorteile bringt dies dem Steuerungsentwickler im Industrie-/ Automotive-Bereich, der bereits eine andere Entwicklungs- umgebung liebgewonnen hat und bisher hauptsächlich in C (oder auch C++) programmiert? Weiterhin ist von abgespeckten .NET-Bibliotheken die Rede, aber was diese genau beinhalten, konnte ich auf die Schnelle nicht herausfinden. Auch für die "klassische" Mikrocontrollerprogrammierung in C gibt es vielfältige Programmbibliotheken aus unterschiedlichen Quellen (vom Controllerhersteller und von Drittanbietern, für Geld und umsonst, ohne und mit Quellcode). Was ist an diesen .NET-Bibliotheken so besonderes? Die Wikipedia-Artikel http://de.wikipedia.org/wiki/.NET_Micro_Framework http://en.wikipedia.org/wiki/.NET_Micro_Framework beantworten trotz ihrer Kürze mehr Fragen als die MS-Übersichtsseite. Was mich ein wenig gewundert hat, dass der Byte-Code der Programme grundsätzlich nur interpretiert und nicht wie auf PCs in Native-Code kompiliert werden. Auf PCs hat man ja mittlerweile Rechenpower im Überfluss, wenn man nicht gerade Power-Gamer ist. Da ist die Verringerung des Softwareentwicklungsaufwands sicher ein stärkeres Argument als die Laufzeiteffizienz. Aber auf einem ARM7? Bei Produkten, wo bei den Herstellkosten jeder Cent zweimal umgedreht wird? Gerade da sollte doch alles eingesetzt werden, was die derzeitige Compilertechnik hergibt. Dass der Native-Code-Compiler nichts auf dem Zielsystem zu suchen hat, ist schon klar. Aber er könnte ja genauso gut auch auf dem Entwicklungsrechner laufen. Oder würde das die .NET-Philosophie sprengen?
Also, zuerst mal zu meinem Hintergrund: Ich kenne das "große" .NET-Framework auf PCs und das Compact Framework für Windows CE, aber das Micro-Framework noch nicht. Außerdem hab ich Erfahrung mit C++-Entwicklung auf PCs und mit C- und C++-Entwicklung auf diversen Microcontrollern. 1. Managed Code --------------- Der Managed Code von C#/.NET erspart es dem Entwickler, sich um Speichermanagement zu kümmern, und das ist in Anwendungen, die viel mit Speicher hantieren, ein echter Segen. Keine Speicherlecks mehr, keine Heap Corruption, der Gewinn an Entwicklungstempo ist schon beachtlich. Die Laufzeit-Performance über alles steigt auch, weil der Speicher dann aufgeräumt wird, wenn der GC etwas Zeit frei hat und nicht dann, wenn der Programmierer free() aufruft. Man braucht natürlich etwas Speicherreserve, damit das Ganze rundläuft und der GC nicht bei jeder kleinen Anforderung die Reste zusammenkratzen muss. Es ist also nichts für minimalistische Systeme - bei Wikipedia stehen ja die Anforderungen 512 K ROM und 256 K RAM. 2. Programmierung in C# ----------------------- Halte ich auch für einen Fortschritt. Der Compiler deckt mehr Fehler auf als ein C++-Compiler (und als ein C-Compiler sowieso), das kann nur gut sein. 3. Programmierung mit Visual Studio ----------------------------------- Ist natürlich hauptsächlich für die Leute ein Gewinn, die das Studio schon kennen - denen wird der Einstieg erleichtert. Aber auch wer bei uC's zuhause ist, kriegt ein sehr gutes Werkzeug angeboten. Hingucken lohnt sich (außer für vi-Fanatiker). 4. Kein Echtzeitsystem, kein echtes Multithreading -------------------------------------------------- Das kann - je nach Anwendung - ein Mangel sein. Wer darauf angewiesen ist, kann .NET Micro nicht gebrauchen. 5. Geschwindigkeitsverlust durch CLR-Interpreter ------------------------------------------------ Das ist der Preis, den man dafür zahlt, dass man sich von Managed Code verwöhnen lässt. Lässt sich umgehen durch native Implementierung (in C) und Aufruf über Platform-Invoke, aber dann ist der Managed-Code-Vorteil zumindest im nativen Teil auch dahin. Auf jeden Fall ists gut, dass man abwägen kann, was einem wichtiger ist. 6. Klassenbibliothek -------------------- Wie wertvoll die Klassenbibliothek vom .NET Micro ist, kann ich nicht sagen, nicht weiß, was alles weggelassen wurde gegenüber den größeren Varianten (Windows und CE). Das Design und Handling der .NET-Bibliotheken ist aber im allgemeinen sehr gelungen. 7. Fazit -------- > Aber welche Vorteile bringt dies dem Steuerungsentwickler > im Industrie-/ Automotive-Bereich ... Kurzfristig vermutlich keine. Dagegen sprechen umfangreiche vorhandene C-Bibliotheken, die höchstens langfristig zu ersetzen sind, sowie besonders im Automotive-Bereich Vorgaben der Hersteller (MISRA & Co.). Mittelfristig liegen z.B. die Vorteile integrierter Komponenten (Display, Akkuüberwachung, Netzwerk, drahtlose Verbindungen, Flash/EEPROM) schon auf der Hand, zumindest für Industrie-Steuerungen. Auch die Beschleunigung der Entwicklung durch verbesserte Fehlererkennung und -behandlung ist ein Vorteil. Wichtigste Argumente dagegen bleiben wohl der höhere Speicherverbrauch, die schlechtere Performance und die fehlende Echtzeit.
>Dass der Native-Code-Compiler nichts auf dem Zielsystem zu suchen hat, >ist schon klar. Aber er könnte ja genauso gut auch auf dem >Entwicklungsrechner laufen. Oder würde das die .NET-Philosophie >sprengen? Dann müsste .NET/C# konkurrieren mit den bestehenden Compilern, und würde verlieren. D.h. auf Grund der vielen Architekturen gibt es für jedes System optimierte Compiler. Gegen all diese würde .NET antreten müssen. Im Endeffekt würde der erzeugte Code nicht so optimiert sein wie bei den spezialisierten Compilern. Es wäre eine Front aus Microsoft gegen den Rest der Welt. Ergo: geht man den Weg über den P-Code einem vorkompilierten Microcode der für alle Architekturen gleich ist und dann von einem für die jeweilige Architektur spezialisierten P-Code Interpreter ausgeführt wird (und verkauft es das als Argument eines Vorteiles) Da man nun ein grundsätzlich anderes Produkt anbietet, mit wenig Konkurrenz macht das Sinn. Vortel ist auch das Microsoft so quasi Kontrolle über eine neu erschaffene Zwischenschicht vom Controller hin zur Endanwendung des Entwickler erlangt. MS kontrolliert dann den P-Code, die Werkzeuge zum P-Code erstellen und die Standardisierung des P-Code/Interpreters selber. Somit bindet Microsoft zwei wichtige Partner bei der Entwicklung neuer Systeme an sich, nämlich die Entwickler der Software und die Hardwarehersteller. Ökonomisch/Marketingtechnsich ein sehr clevers Konzept das nur gebrochen werden kann indem es auch freie/opensource P-Code-Compiler und Interpreter gibt. Und da greift die Vorgehensweise von Micrososft die wir aus anderen Bereichen kennen. Erst schafft man gemeinesamme Standards, wie JAVA/HTML/DCOM/SOAP usw. und dann baut MS diese Standards über seine Endanwendungen wie INet-Expolerer mit eigenen Features aus die später zum Standard werden müssen. Also selbst wenn es Opensource P-Code Compiler/Interperter gäbe so würde am Ende eine Situation eintreten bei der MS über seine Nicht-Standard-konformen Erweiterungen ein Diktat ausübt. Denn schlußendlich entscheidet der Käufer der Systeme das er neue Features haben möchte, und wenn es schön bunt ist so wird er es auch akzeptiert, siehe Windows Media Player und das dort eingeführt WMA/WMV Dateiformat, das absolut prohibitär ist und TCPA einführt. Gruß Hagen
Das DotNet zeugs bringt ja nur was wenn man ein graphisches Benutzer interface auf einem Device haben will. Falls man an einen ARM ein TFT anschliessen will und dem Bentzer eine Windowsoberflaeche bieten will ist man genau richtig. Fuer ein Echtzeitsystem, Regelung, irgendwas bringt das gar nichts.
> Das DotNet zeugs bringt ja nur was wenn man > ein graphisches Benutzerinterface auf einem Device > haben will ... Jein. Es gibt auch Kommunikations-Schnittstellen, Datenverwaltungs-Klassen (Listen, Lookup-Maps usw.) und anderes. > Fuer ein Echtzeitsystem, Regelung, irgendwas > bringt das gar nichts. Das mag stimmen. Aber es gibt auch andere Anwendungen als GUI und Regelung. Prozessbeobachtung, CAN-to-Ethernet-Umsetzer, Datenlogger, drahtlose Überwachung - nicht immer muss im Millisekundentakt geregelt werden.
Kommunikationsschnittstellen, Listen, lookups, Logger und sowas wird nie ein DotNet rechtfertigen, da es einfach zu trivial ist, resp. als public domain schon lange geloest wurde. Sorry.
Die Echtzeitproblemeatik ist irrelevant, wenn man in längeren Zeiträumen denkt. Das was heutzutage mit .NET, P-Code-Interpreter und einem zb. ARM9 nicht als Echtzeitsystem eingestuft würde, wird in par Jahren als Echtzeitsystem eingestuft werden. Einfach weil die Rechenleistungen immer weiter steigen. Es ist heute schon üblich das Rechnerarhitekturen intern einen Microkernel besitzen, qausi ein Interperter für Maschinencode, und diese laufen auch in Echtzeit. Echtzeit ist eine Definitionsfrage, was ist Echtzeit für eine Schnecke ? Echtzeit definiert sich nur aus den Anforderungen der Reaktionsgeschwindigkeit der abzuarbeitenden Prozesse. Ist der Prozess träge/langsam dann ist aus Sicht der Zielsetzung auch Echtzeit langsam. Gruß Hagen
Echtzeit hat ja weniger mit Geschwindigkeit, sonder viel mehr mit Rechtzeitigkeit zu tun. Die Rechtzeitigkeit kann aber nur dann gewährleistet werden, wenn das Systemverhalten vorhersagbar ist, d.h. für Reaktionszeiten auf externe Ereignisse obere Schranken angegeben werden können. Aus einem Nichtechtzeitsystem wird also durch bloße Erhöhung der Rechengeschwindigkeit kein Echtzeitsystem. http://de.wikipedia.org/wiki/Echtzeitsystem Mikrosoft selber bezeichnet bspw. Windows CE als echtzeitfähig, NETMF hingegen nicht. Das liegt hauptsächlich am Garbage-Collector, dessen Zeitverhalten sehr stark von Speicherfüllgrad und -fragmentierung abhängt und damit fast nicht vorhersagbar ist. Der GC ist auch der Grund, warum sich Java nie so richtig in Echtzeitsystemen behaupten konnte, obwohl es mittlerweile etliche Ansätze gibt, das GC-Problem zu lösen. Der P-Code-Interpreter an sich ist kein Grund für die Nichtechtzeit- fähigkeit, da er das System zwar bremst, aber um einen Faktor, der nach oben abschätzbar ist.
Naja, daß sich GC und Echtzeitfähigkeit so gut wie ausschließen ist ja bekannt. "Herr Bußfahrer, wie kam es denn zur Kollision? A: Keine Ahnung, war gerade hinten beim Kassieren!"
Entscheidend wird die Hardware-Unterstützung sein. Nicht umsonst hat sich Java auf Mobiltelefonen durchgesetzt. Heutzutage ist doch in den meisten Mobiltelefonen ein ARM mit Jazelle drin. Wenn es Microsoft gelingt, Prozessorhersteller - insbesondere ARM - zu überreden, eine Hardwareunterstützung für .NET zu implementieren, dann wird es einen signifikanten Marktanteil bekommen, andernfalls werden es nur die eher unterdurchschnittlich qualifizierten Entwickler nutzen, die anders nicht zum Ziel kommen und darum auf teure und stark überdimensionierte Hardware setzen müssen.
Wird auch eine Kostenfrage sein. Ich habe kuerzlich einen Javaprozessor gesehen. Der geht fuer gegen 20 Euro, verglichen mit einem 4 Euro ARM bei mittleren stueckzahlen.
Ich beschäftige mich seit 2006 ausgiebig mit dem .NET Micro Framework (ohne Eigenwerbung zu machen). Ich habe nicht zu viel Zeit, weswegen ich mich gerade mit dem Teil befasse. Niemand sagt, dass das MF für alle Anwendungszwecke geeignet ist. Echtzeitverhalten: Echtzeit is nich, der Garbage-Collector legt alle Threads für ca. 20 ms lahm und ne ISR kann schon mal ein paar ms später aufgerufen werden. Wer also mit ner Reaktionszeit von 20-50 ms auskommt, für den ist das MF geeignet. Klassenbibliothek/C# Die Klassenbibliothek beinhaltet einiges aus der PC-Version und alles was übernommen wurde ist kompatibel. Dazu gibt es spezielle Klassen zur Ansteuerung der Hardware. Das heißt man kann Algorithmen, Datenstukturen und Sonstiges bedingt vom PC, Smartphone oder PDA übernehmen und kann in der gleichen Programmiersprache und Entwicklungsumgebung (Visual Studio) bleiben. Debugging/Hardware-Emulation Der Hardware-Emulator ist mein liebstes Spielzeug. man kann sehr einfach seine zukünftige Hardware mit Peripherie nachbilden und einen schnellen Prototypen bauen. Das ganze dem Kunden vorgeführt kann somit mit der Anwendungsentwicklung begonnen werden bevor die hardware steht und auch das endgültige Design kann durch die Emulation beeinflusst werden. Fazit: Je komplexer die Anwendung z.B. Grafik/Netzwerk/Webservices (Entwicklungskosten) usw. und je geringer die Stückzahlen (Hardwarestückkosten) desto geeigneter ist das MF. Das muss also jeder selber überlegen, ob er mehr an Entwicklungskosten/Zeit oder an den Stückkosten der Hardware sparen will.
Wenn du schon mit Java auskennst, dann gibt es eine Java-VM namens Squawk [https://squawk.dev.java.net/], die ohne BS lauffähig ist. Die VM ist unter anderem in SunSPOTs [http://www.sunspotworld.com/] verwendet. Diese VM ist im Gegensatz zu .NET Open-Source und kann/darf für jede CPU-Architektur portiert werden. Die min. Hardwareanforderung: 16 KB RAM und 512 KB ROM.
Was kostet das .net Micro Framework eigentlich? Ich hab dazu rein garnichts gefunden? Wie verdienen die ihr Geld?
Das Framework kostet nix (zumindest die großen beiden). Die verdienen ihr Geld z.B. mit Visual Studio und diversen anderen Produkten.
Und das kostet dann nicht pro verkauftem Gerät oder sowas? Es würde mich wundern wenn sich M$ das Geld entgehen lassen würde. Gut wärs ja.
Naja, Microsoft verschenkt ja auch einen vollwertigen SQL Server und eine vollwertige Entwicklungsumgebung mit dem Anhängsel "Express" mit kleinen Einschränkungen.
Willivonbienemaya .. wrote:
> Und das kostet dann nicht pro verkauftem Gerät oder sowas?
Doch: eine Windows-Lizenz. Die ist ja wohl teuer genug, als dass
sie damit ihren Reibach machen...
Hmm, soweit ich weiß, läuft das .Net Microframework aber nicht unter Windows sondern direkt auf der Hardware. ich glaube auch nicht, das MS es schafft, ein Windows in ein paar KB Code und ein paar KB Ram unterzubringen... Ausserdem haben die meisten Microcontroller Anwendungen ja gar kein bzw. nur ein sehr rudimentäres Benutzerinterface in Form eines LCDs o.ä.
Jan Krause wrote: > Hmm, soweit ich weiß, läuft das .Net Microframework aber nicht unter > Windows sondern direkt auf der Hardware. Ah, OK, ich hatte das "Micro" überlesen (bzw. nicht mehr in Erinnerung).
auf dem Device läuft ja auch kein Windows, nur eine CLR und für die wird eine Volumenabhängige Runtimelizenzgebühr fällig. Die dürfte aber nicht sehr hoch sein, für CE Devices z.B. (je nach eingebauten Modulen) liegt man soweit ich weiss bei ca. 15 US$, da ist dann aber schon ein 'fettes' OS dabei. Die CLR Lizenz dürfte also noch weit darunter liegen.
JojoS wrote: > auf dem Device läuft ja auch kein Windows, nur eine CLR und für die wird > eine Volumenabhängige Runtimelizenzgebühr fällig. Gibt es dazu Quellen von Microsoft? Ich habe sowas bis jetzt noch nicht gelesen.
ja, so habe ich es in einem whitepaper von MS gelesen, suche den Link später nochmal raus.
Hier ist der Link. Stehen aber wohl keine konkreten Zahlen drin. Hängt sicher ab vom Volumen des Auftrags Prozessorplattform etc. http://www.google.de/url?sa=t&source=web&ct=res&cd=2&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2Fa%2F9%2Fc%2Fa9cb2192-8429-474a-aa56-534fffb5f0f1%2F.NET%2520Micro%2520Framework%2520White%2520Paper.doc&ei=KlgRSYioG4--0gXzxpDDCw&usg=AFQjCNEhC4DH64e4AeOpR6ZO-N3OzmoNug&sig2=rN4YszfmM1LG4Ew0fddLyg
Mike wrote: > Wenn es Microsoft gelingt, Prozessorhersteller - insbesondere ARM - zu > überreden, eine Hardwareunterstützung für .NET zu implementieren, dann > wird es einen signifikanten Marktanteil bekommen. Ist schon gelungen. Allerdings weiß ich nicht, ob tatsächlich MS dahintersteckt. "Jazelle-RCT" ist fester Bestandteil der ARM Architektur v7-A (optional in v7-R) und unterscheidet sich von "Jazelle-DBX" (traditionelles Jazelle) dadurch, dass es eben nicht auf Java festgelegt ist. Prinzipiell können alle byte compiled (insbesondere auch run-time compiled) Sprachen unterstützt werden. Eine ELisp Engine auf einem Cortex-A8 wäre schon fein ;) Gruß Marcus
DevBoard für .net microframework zu verkaufen: siehe Beitrag "DevBoard für .net MicroFramework zu verkaufen"
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.