vishia

ZBNF / XML

- ZBNF syntax descr

JZtxtcmd / Zmake

- main description

- Zmake

Docu Generation

vishia-Java

Java and Embedded Systems

CRuntimeJavalike

Java2C

Softwaretechnology

- -Dependencies

- -QuellcodeGenerierung

Inspector & Reflection

- Test on Runtime

- The inspector tool

- Reflection in C

- Inspector Communication

Graphical Programming

Model based - Modelica

Model based - Simulink

Fcmd

Download Page

 

 

 

 

C oder C++ sind als Implementierungssprachen in der Embedded Welt weit verbreitet oder genauer gesagt die Favoriten. C++ hat sich dabei in den letzten Jahren auch bei seltenen Prozessoren durchaus etabliert. Allerdings sprechen einige Gründe dafür, weiterhin auf C zu setzen.

Doch es gibt eine Nach-C-Ära. Diese ist spätestens mit Java eingeleitet. Java ist nicht nur der Favorit in Internet- verteilten Anwendungen- und PC-Programming, sondern ist auch in vielen Geräten als embedded Software präsent. Java ist konsequent objektorientiert und damit softwaretechnologisch besser. Ein Hauptpunkt ist die Sicherheit der Software. Sicherheit hat dabei zwei Aspekte:

  • Sicherheit bezüglich der Programmierung, Fehleranfälligkeit, TimeToMarket fehlerarm

  • Sicherheitsrelevante Software.

Java hat nur den Makel der Nicht-Echzeitfähigkeit. Dabei geht es nicht um Schnelligkeit (typisches Argument von Java-Kritikern: Die VirtualMachine wäre ein Interpreter daher langsam, stimmt nicht, JIT (Just In Time)-Compiler heben diesen Nachteil auf. Und etwas längere Startup/Ladezeiten sind woanders auch akzeptiert). Der Schwachpunkt ist das Prinzip der Garbage Collection, was für bestimmte Zeiten über -zig Millisekunden die Bearbeitung auch mal blockiert.

Nun gibt es in der JTRES (Java Technologies for Real-time and Embedded Systems)-Szene auch darauf Antworten. Das sind beispielsweise der unterbrechbare Garbage-Collector, wie er in der Jamaica-VM implementiert ist. Aber die Entscheidung für Java ist eine weitgehende Systementscheidung, die nicht überall gegangen wird.

Weitere Links