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_Frameworkhttp://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.
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.
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
