mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Was bringt der Einstieg ins .NET Micro Framework?


Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: 3348 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: 3348 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rüdiger Knörig (sleipnir)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!"

Autor: Rüdiger Knörig (sleipnir)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NS: Tue für den Bußfahrer Buße...

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 3348 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens Kühner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Java (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was kostet das .net Micro Framework eigentlich?
Ich hab dazu rein garnichts gefunden?
Wie verdienen die ihr Geld?

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Framework kostet nix (zumindest die großen beiden). Die verdienen 
ihr Geld z.B. mit Visual Studio und diversen anderen Produkten.

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, Microsoft verschenkt ja auch einen vollwertigen SQL Server und 
eine vollwertige Entwicklungsumgebung mit dem Anhängsel "Express" mit 
kleinen Einschränkungen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.ä.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, so habe ich es in einem whitepaper von MS gelesen, suche den Link 
später nochmal raus.

Autor: Jan Krause (jeangonzales)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mfuser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DevBoard für .net microframework zu verkaufen:

siehe Beitrag "DevBoard für .net MicroFramework zu verkaufen"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.