Hallo!
Wer hat Lust und Laune eine Linux-Lib zu teste?
Ich habe eine Bibliothek unter Linux programmiert mit der man Daten über die serielle Schnittstelle austauschen kann. Dabei habe ich mich an der Win-Lib MVCOM orientiert, d.h., es werden die gleichen Befehle genutzt. Somit ist eine Portierbarkeit der Win-Programme nach Linux und umgekehrt möglich.
Wer möchte kann sich die Lib hier herunter laden:
http://www.mgross.gmxhome.de/serial_lib.tar
Alles weitere steht im Hilfetext.
Gruß Matze
Testen einer Linux-Lib!?
Momentan funzt mein PB unter linux nicht, aber ich würde dich bitten diese Lib auch im engl. Forum zu posten, denn es ist nach meiner Sicht absolut wichtig dieses Schnittstellen (zum Bsp für IF-Fernbedienung) auch unter LIN zu bedienen zu können .
Ich hoffe aber auch das ich ende der woche dazu komme diese lib zutesten.
Ich hoffe aber auch das ich ende der woche dazu komme diese lib zutesten.
Rings hat geschrieben:ziert sich nich beim zitieren
Interessieren tät' mich das schon sehr. Ich hab hier ein Biofeedback, das den Hautwiderstand und dessen Änderungen über den com-port sendet. (Thoughtstream)
Verwendet wird dies einerseits um Veränderungen im Entspannungszustand anzuzeigen, aber viel interessanter sind diese Daten als Steuerung von Mental-Games (die auch beim Thoughtstream mitgeliefert werden, aber sehr mager von den Ideen her sind), aber auch zB Wild Divine (was aber leider USB verwendet, dürfte schwieriger sein) benutzt als Steuerung teilweise Biofeedback (Hautwiderstand).
Spielaufgabe zB eine Tür zu öffnen durch einen Entspannungszustand, der soundsoviel vom Durchschnitt der letzten paar Minuten abweicht, aber auch viele andere Anwendungen sind denkbar...zB "Echtzeitpoweränderungen" einer Spielfigur...
Werd mal gucken, ob ich irgendwie eine Ausgabe von Werten hinbekomme.
Gruss
Mipooh
Verwendet wird dies einerseits um Veränderungen im Entspannungszustand anzuzeigen, aber viel interessanter sind diese Daten als Steuerung von Mental-Games (die auch beim Thoughtstream mitgeliefert werden, aber sehr mager von den Ideen her sind), aber auch zB Wild Divine (was aber leider USB verwendet, dürfte schwieriger sein) benutzt als Steuerung teilweise Biofeedback (Hautwiderstand).
Spielaufgabe zB eine Tür zu öffnen durch einen Entspannungszustand, der soundsoviel vom Durchschnitt der letzten paar Minuten abweicht, aber auch viele andere Anwendungen sind denkbar...zB "Echtzeitpoweränderungen" einer Spielfigur...
Werd mal gucken, ob ich irgendwie eine Ausgabe von Werten hinbekomme.
Gruss
Mipooh
Hallo!
Ich habe am WE ein wenig die Lib erweitert und die beiden gewünschten Befehle mit eingearbeitet.
Hier die aktuelle Version
http://www.mgross.gmxhome.de/serial_lib_040405.tar
Gruß
Matze
Ich habe am WE ein wenig die Lib erweitert und die beiden gewünschten Befehle mit eingearbeitet.
Hier die aktuelle Version
http://www.mgross.gmxhome.de/serial_lib_040405.tar
Gruß
Matze
Hallo!
Bei mir funktioniert die lib leider nicht.
Getestet habe ich es auf 2 Rechnern mit Suse 8.2 und 9.2 und einem nullmodem.
Ich habe aber momentan hier zimmlich komische Probleme. Wenn ich die Schnittstelle über ioperm(..) und outb(..),inb(..) ansteure dann funkitoniert alles. Aber wenn ich versuche mit read(..) von ttyS0 zu lesen dann bleibt das Programm bei read(..) hängen.Senden funktioniert aber, z.B: ls > /dev/ttyS0.
Mit deiner lib kann ich auch nichts empfangen.
Hätte sein können das die RS232-Schnittstelle beschäditgt ist und aber ich bekomme identischen Ergibnise auf zwei unterschiedlichen Rechnern.
So viel kann ich momentan sagen.
Bei mir funktioniert die lib leider nicht.
Getestet habe ich es auf 2 Rechnern mit Suse 8.2 und 9.2 und einem nullmodem.
Ich habe aber momentan hier zimmlich komische Probleme. Wenn ich die Schnittstelle über ioperm(..) und outb(..),inb(..) ansteure dann funkitoniert alles. Aber wenn ich versuche mit read(..) von ttyS0 zu lesen dann bleibt das Programm bei read(..) hängen.Senden funktioniert aber, z.B: ls > /dev/ttyS0.
Mit deiner lib kann ich auch nichts empfangen.
Hätte sein können das die RS232-Schnittstelle beschäditgt ist und aber ich bekomme identischen Ergibnise auf zwei unterschiedlichen Rechnern.
So viel kann ich momentan sagen.
Amilo 1667|Suse Linux 10.1_64bit/WinXP |PB 4.00/3.94
Bei dem Zugriff mit read() wartet das Programm auf eintreffene Daten in dem Lesepuffer, dieses kann man aber duch setzen eines Flags unterbinden.
In meiner Lib ist diese Verhalten schon deaktivert, daher wird beim Lesen eines leeren Puffers Null zurückgegeben.
Bist du dir sicher, dass du ein Nullmodenkabel verwendet hast (TX und RX sind gekreuzt)?
Gruß
Matze
PS: Lese- und Schreibrechte auf "ttyS0" setze ich voraus.
In meiner Lib ist diese Verhalten schon deaktivert, daher wird beim Lesen eines leeren Puffers Null zurückgegeben.
Bist du dir sicher, dass du ein Nullmodenkabel verwendet hast (TX und RX sind gekreuzt)?
Gruß
Matze
PS: Lese- und Schreibrechte auf "ttyS0" setze ich voraus.
Ich bin mir totsicher, ich habe es selbst zusammengelötet.Bist du dir sicher, dass du ein Nullmodenkabel verwendet hast (TX und RX sind gekreuzt)
Übrigens nach diesem Schema:http://www.loop-back.com/null-mod.html
Na ja, es wäre komisch was anderes zu erwarten. Berechtigung sitmmt auch.Lese- und Schreibrechte auf "ttyS0" setze ich voraus.
Ich muss es also zu erst ohen deine lib hinbekommen um zu wissen woran es liegt.
Amilo 1667|Suse Linux 10.1_64bit/WinXP |PB 4.00/3.94
Ist die Schirmung des Kabels in Ordnung und ist es auch nicht zu lang?
Bei selbsgebauten Kabeln kann es schnell zu Störungen kommen, d.h., es ist nicht möglich mit hohen Übertragungsraten zu arbeiten.
Tritt der Fehler auch bei kleinen Baudeinstellungen auf?
Es gibt sonst auch die Möglichkeit mit einem Stecker in dem TD und RD miteinander verbunden sind das Senden und Empfangen an einer Schnittstelle zu testen. Man brauch dann keinen zweiten Rechner oder auch keine zweite Schnittstelle.
Bei selbsgebauten Kabeln kann es schnell zu Störungen kommen, d.h., es ist nicht möglich mit hohen Übertragungsraten zu arbeiten.
Tritt der Fehler auch bei kleinen Baudeinstellungen auf?
Es gibt sonst auch die Möglichkeit mit einem Stecker in dem TD und RD miteinander verbunden sind das Senden und Empfangen an einer Schnittstelle zu testen. Man brauch dann keinen zweiten Rechner oder auch keine zweite Schnittstelle.