Java und Parallel-Port Antwortzeiten

Hi

wie du schon selber bemerkt hast: Windows ist kein RT OS. Es besteht
also durchaus die Möglichkeit das deinem Java Programm (bzw. der Java
VM) für mehr als 50ms der Prozessor entzogen wird. 50ms würde ich sogar
für nicht sehr unwahrscheinlich halten.

Matthias

Wie sieht es im Vergleich Java - Visual C aus?

Liegen die Probleme am OS und sind von der Programmiersprache
unabhängig, oder schneidet Java (z.B. wegen VM und Garbage Collection)
schlechter ab als C?

Also unter DR-DOS klappt das mit dem 50ms, und DOS ist nun ja auch
nicht besonders RT geeingnet. Nun muss aber eine Windowsanwendung
her...

MfG,
Michale

Hi

DOS ist nicht RT geeignet? Wer erzählt den sowas. Unter DOS gehört dir
der Prozessor ganz alleine. Antwortzeiten im Bereich einiger µs sollten
unter DOS überhaupt kein Problem sein.

Unter Windows kann dir der Scheduler aber einfach so den Prozessor
entziehen. Du kannst zwar die Priorität deines Prozesses hochdrehen
aber ob das soweit geht das man die 50ms garantieren kann weiß ich
leider nicht. Multi-Processing und Echtzeit beißen sich halt. Ohne
speziell dafür optimierten Scheduler kann man Antwortzeiten nicht
garantieren.

C/C++ dürfte sich etwas besser eignen da da nicht noch eine Schicht
zwischen Prozessor und Anwendung liegt.

Matthias

Schreibt doch bitte nicht solch ein Blech, Michael, schau dir bitte mal
das javax.comm package an, gibt's bei java.sun.com, damit kannst du
Inputstreams auslesen, schau's dir einfach mal an...

Hi

wer hat den bezweifelt das es nicht geht eine Par/Ser. Port mit Java
auszulesen. Es garantiert nur niemand 50ms Antwortzeit.

Matthias

tjo so richtig garantieren lann das kein os... es sei denn es ist ein
rtos das time slicing macht ;)

unter win sollten eigentlich 50ms bei recht hoher thread priorität
eigentlich drinnen sein... hängt aber von der prozessorlast ab...

73 de oe6jwf / hans

Hey,
war je net so bös gemeint. Schaut euch mal die "jnpout32.dll" an
(google). Hab damit nen Mini-Weihnachtsbaum über den LPT-Port zum
Leutchen gebracht, basiert letzendlich auf JNI (sry, javax.comm is net
geeignet gewesen) bzw. der WinAPI.
Und 50ms sind da gar kein Thema...

Gruß

Hi Leute, Hallo Namensvetter

50ms sind mit Windows (95) eigentlich schon machbar, jedenfalls kann
man damit Servos steuern. Die wollen alle 20ms für ein paar ms einen
Impuls... OK, unter Windows ruckelts ein bisschen, aber es geht - und
zwar sogar im interpretierten QBasic-Modus - OK, ist nicht ganz
Java...

Gruss

Michael

Dass es mit Win95 klappt ist gut möglich da Win95 auch auf MS-DOS
basiert bzw. dies als Grundlage benutzt.
Bei den neueren Windows Versionen 2000 & XP kann es klappen, muss es
aber nicht unbedingt.

Also, ich beutze die JAVA communications API zum Zugriff auf
Schnittstellen, und kann die auch empfehlen. Nun aber was neues:
System.currenttimemillis() liefert die Zeit (nach meinen Experimenten)
mit einer Auflösung von etwa 10ms, Thread.sleep [garantiert] dir eine
feinere Auflösung. Man sollte halt nur das JAVA-Programm am laufen
haben und nicht nebenbei 10000 Stellen von PI berechnen...

Die 10 ms von Roman sind die übliche Schedulergranularität der
ernstgemeinten Windows-Versionen. Die kann übrigens mit einer der
"multimedia-Timer"-Funktionen* auf 1 ms herabgesetzt werden - es
entzieht sich allerdings gänzlich meiner Kenntnis, wie man das aus
einer Java-Anwendung heraus macht.


*) timeBeginPeriod, deklariert in mmsystem.h

Es ist vielleicht sinnvoller den zeitkritischen Zugriff in einen
(Kernel-)Treiber zu packen.
Achtung nur für Fortgeschrittene Programmierer, nicht für ungeübte
geeignet. Dort sind dann sehr schnelle Antwortzeiten möglich.

Gruss