RS232/USB-Signale in Java weiterverarbeiten

[Tecwan]

Hallo, ich möchte einen alten GPS-Empfänger am Netbook auslesen und dessen Daten anschließend
per Java weiter verarbeiten.

Ich habe einen RS232/USB-Konverter, der auch als COM unter System 7 des Netbooks erkannt wird.
javax.comm läuft ebenfalls und findet den entsprechenden COM-Port.

Das Problem:
Ich möchte nicht auf dem winzigen (32-bit) Netbook entwickeln, sondern auf meinem Desktop-
Rechner.
Dieser läuft ebenfalls unter System 7, allerdings - wie könnte es auch anders sein - mit 64-bit.
Und das verträgt sich natürlich nicht mit der win32com.dll der javax.comm:

Can't load IA 32-bit .dll on a AMD 64-bit platform

Nun kann ich natürlich auf dem großen Rechner "entwickeln" und bei Testläufen das .jar auf das
Netbook schieben und dort laufen lassen; übermäßig komplex ist das Ganze nicht, und System.out's
lassen sich zur Not auch in Labels schreiben - nun ja, man kann vieles...

Also heißt die Lösung wohl RXTX, da Cloudhopper eine 64-bit .dll bereit stellt.
Allerdings hat auch diese schon ein paar Jährchen auf dem Buckel, Windows 7 gab es noch nicht.
Reichen dabei die von Cloudhopper stammenden RXTXcomm.jar und rxtxSerial.dll aus, oder brauche
ich zusätzlich noch was von rxtx? (Parallel bleibt außen vor)
Ich weiß dass ich gnu.io.* importieren muss anstelle javax.comm.*

Ich entwickle mit dem JDK 1.7, auf dem Netbook läuft die JRE 1.6.
Sind von dieser Seite her Probleme zu erwarten?
Was den Code angeht, gibt es hinsichtlich der seriellen Schnittstelle ja eh keine Änderungen, aber
in den BuildProperties zu den Cloudhopper-Dateien wird als Java-Version "1.6.0_10" angegeben.

Generell: Hat jemand bereits praktische Erfahrungen mit seriell/USB-GPS-Datenlieferanten an
Windows System 7-Javaprogs gemacht?

 

[irgendjemand]

1) installier auf deinem desktop einfach die 32bit VM ...
dazu solltest du aber erstmal die 64bit VM deinstallieren ... dann die 32bit VM ... und dann die 64bit VM hinterher ... damit dein system auch standardmäßig die 64bit VM nutzt ... ansonsten überschreibt die 32bit VM einiges und das system nutzt als standard dann nur die 32bit VM

2) wenn du mit J7 compilest musst du "-target 1.6 -source 1.6" als parameter angeben damit der kram für J6 compilet wird und ausführbar ist ... ansonsten bekommst du die bekannte "major-version-mismatch" an den kopf ... was dann so viel heißt das du eine klasse mit einem neueren JDK compiled hast ... aber versuchst sie mit einer älteren VM auszuführen ...

 

[Tecwan]

Danke für die Hinweise.
Aber auf meinem Desktop-Rechner laufen beide VM, und wie mir bisher scheint, auch ziemlich
sauber getrennt.
Ich nehme an, dass die JRE 1.6 von einem anderen Prog installiert wurde, LibreOffice, OpenOffice
oder etwas in der Art.
Ich könnte unter NetBeans als Library für das Projekt auch eine andere als die JDK 1.7 angeben,
aber bisher sehe ich dafür keine Veranlassung.

Bisher haben sämtliche Projekte, die ich mit JDK 1.7 entwickelt und als .jar auf anderen Rechnern
eingesetzt habe - dort laufen zumeist die JRE 1.6 - anstandslos funktioniert.
Den major-version-mismatch habe ich noch nie zu Gesicht bekommen. Ich gehe mal davon aus,
dass dies erst dann der Fall sein wird, wenn ich Klassen verwende, die auf erst mit 1.7
hinzugekommenen Features basieren.

Daher werde ich es erstmal dabei belassen.


Inzwischen habe ich RXTX auf beiden Rechnern installiert.
Da mich nur die serielle Schnittstelle interessiert, sind dies lediglich die 2 Dateien, wobei ich annehme,
dass

RXTXcomm.jar

in beiden Versionen identisch ist.
Dann würde sich nur die

rxtxSerial.dll

je nach bit-Version unterscheiden.
Liegt die aufgerufene JRE im Ordner

Programme (x86)

, müsste ein Installer (oder ein quick and dirty
Paste der jeweiligen im eigenen jar mitgegebenen dll) hierhin die x86-Version der

rxtxSerial.dll

kopieren, im Fall des Aufrufs der JRE aus dem Ordner Programme die x64-Version.
Ich habe das noch nicht getestet, sondern händisch gemacht.
Aber vielleicht probiert das ja einer der geschätzten Leser hier aus und postet etwas dazu.


Das Einlesen von Daten funktioniert funktioniert bei mir, und zwar auf beiden Rechnern, wobei
unterschiedliche COM-Ports verwendet werden.
Zu Beginn der Kommunikation hakt es allerdings; zunächst kommt anstelle sauberen ASCII nur
Müll an. Ich denke, dass es Synchronisationsschwierigkeiten gibt, die sich aber nach etwa
100 Bytes dauerhaft geben. Anschließend kommen saubere Datensätze.

Nachdem ich zunächst den einfachen byteweisen

InputStream

verwendet habe, wollte ich,
da die Meldungen vom GPS-Empfänger zeilenweise eintreffen, auf den bequemeren

InputStreamReader

wechseln.
Das führt leider zu einer

java.io.IOException: Underlying input stream returned zero bytes

Hier zeigt sich wohl das Alter: Java liest um Einiges schneller, als Signale über die COM
hereinkommen (kein Wunder, das Gerät schreibt mit 4800 Baud), und die Voreinstellungen der DLL
scheinen da nicht mehr ganz zu passen.
Abhilfe:

serialPort.enableReceiveTimeout(Integer.MAX_VALUE);

gleich nach der Festlegung der Schnittstellenparameter.