OneWire Java Linux

ProtonM

Mitglied
Hallo zusammen

OnewireViewer von Dallas Semiconduktor gibt es in 2 Varianten:
1. via COM mit dem rxtx-Treiber ist der Standard unter Unix
2. via USB mit dem PDKAdaperUSB und einem JNI-Treiber.

Ich benutze den HW-Adapetr DS2490 via USB (Applikation unter XP entwickelt läuft , soll nach Linux portiert werden).
Was habe ich gemacht:
1. libonewireUSB.so als JNI erstellt und installiert.
2. OneWireAPI.jar indstalliert (gibt es auch 2 Varianten für com und USB)

3. OneWireViewer als Java-Applikation gestartet, im
4. User-Kontext, wird der Treber nicht gefunden,
5. Root-Kontext läuft die Applikation einwandfrei.

Frage:
Wie kann ich den Startablauf transparenter machen, sodass ich sehe, welche OneWireAPI.jar und welcher Treiber wo gesucht wird? Gibt es irgendwo ein Log?

Danke für Tipps
 
Hallo Vfl_Freak

Ja, nun, ich fange mit Java an. Und ich will eine Standard-Applikation zum Laufen bringen, die uner XP und Unix-rooot läuft. Wenn die Infrastruktur / Treiber funktioniert, kann ich auch im User-Kontext meine Eigenentwicklung portieren. Um aber eigene Fehler auszuschließen, nehme ich was, was passen sollte.
Oder?

Wenn die Kategorie falsch ist, dann kann das Thema gerne dorthin geschoben werden. Ich habe nichts passenderes gefunden. Dafür möchte ich mich in aller Form entschuldigen.
 
Moin,

Du musst dich nicht entschuldigen 🙂
Es ist nur sicherlich so, dass Du hier durch die falsche / unglückliche Kategoriewahl deutlich weniger (relevante) Antworten erwarten darfst.

Vlt. erbarmt sich sich ein Admin und verschiebt den Beitrag 😉

Gruß Klaus
 
Hallo

Ich habe mal die Ausgaben in eine Datei gepackt.
Was ist der Grund für das unterschiedliche Verhalten?

Dank für eine Antwort. (Auf Destruktives ala Klaus verzichte ich.)
 

Anhänge

Was soll man da viel sagen ausser mal die Zugriffsberechtigungen aller relevanten Dateien und Pfade zu überprüfen ... (evtl. noch environment unter root und user vergleichen)
 
Hallo JStein52
Ich hatte schon mal alles überpürft und von root auf USER korrigiert, aber vielleicht nicht vollständig.

Im Startscript ./run.sh wird ein touch auf die Properties konditional ausgeführt. Bei root erfolgreich, beim owner nicht. Das verstehe ich schon nicht. Die Datei ist im selben Verzeichnis vorhanden.
 

Anhänge

Hallo JStein52

Danke für den Hinweis.
Ja, die Blacklist ist gesetzt und die plugdev Gruppe auch. Inzwischen bin ich ein Stück weiter und suche im Umfeld der HW-Einbindung. Ich kann den OW-Adapter nur beim Booten einbinden und dann fehlt die Nutzerberechtigung.
lsusb liefert die Daten für den Adapter korrekt. Und im syslog finde ich den Eintrag. Allerdings ist im udev-Umfeld etwas faul. Zieht man den Adapter ab, erkennt der Kernel lt. syslog das, aber das nächste Einstecken nicht. Ich muss dann neu Starten und es gibt nur rootrechte für den Adapter.
 
hallo

Zum touch noch eine Ergänzung. Wenn die Datei nicht existiert, wird sie mit dem script angelegt und anschließend im Java-Dialog gefüllt. Das ist also die Ursache nicht.
 
Hallo

Ich bin zwar noch nicht am Ziel, aber erste Ergebnisse seien kurz beschrieben:

MIT lsusb werden Bus- und Device-Numer ausgegeben.

Mit lsusb -vs 001:00x gibt es dann Details für DEVICEPFAD (/dev/bus/usb/001/002).

Mit udevabm info --query-all --name=/dev/bus/usb/001/002 gibt es einen Hinweis auf den DEVICENamen in der Zeile P: /devices /pci0000:00/.....

Der Zeile P wird noch ein /sys vorangestellt und im nächsten verwendet.

Mit udevadm test DEVICENAME (/sys//devices /pci0000:00/.....) werden die Rules gelistet und geprüft. Im Output findet man dann alle Angaben und kann überprüfen ob das ok ist. Vorallem wird die Regel gelistet und die GROUP / MODE Info für die berechtigungen.

Vielen dan allen die mit überlegt haben.
 

Zurück
Oben