Uiuiui. Zu viele Fragen :D. Also.
Zitat
Was macht Dich sicher, dass /dev/ttyUSB0 das richtige Device ist?
Ich muss zu meiner Schande gestehen, dass vor dem Reboot "alles" lief. Ich konnte das Gerät ansprechen und habe auch eine "06" bzw "15" zurück bekommen (ACK bzw NCK). Also stimmt ttyUSB0
Zitat
Es gibt noch wesentlich mehr Parameter, die über stty zu setzen sind, damit eine serielle Datenübertragung reibungslos funktioniert. Hast Du Dich mal über man stty eingelesen?
Japp, das weiß ich. Bei mir reichten aber die wenige Parameter zu setzen. Das Gerät lief dann. Ich hab mir die Befehlte eben vor dem Reboot leider nicht notiert
Zitat
Ob Senden funktioniert, weißt Du auch nicht wirklich?
Doch, siehe oben. Vorm Reboot lief es.
Zitat
Hast Du darauf geachtet, dass über GPIO-Pins RX nur maximale Pegel von 3,3 V eintrudeln dürfen - über USB nur 5 V
Das Gerät läuft NUR über USB. Ich achte also nicht auf 3,3/5V.
Zitat
Es besteht ein Unterschied zwischen stty -F /dev/ttyUSB0 und stty ohne Device-Angabe. Es werden jeweils andere Geräte angesprochen / abgefragt. Deswegen ist die Information der Ausgabe stty belanglos.
Sehr gut, danke. Das wusste ich nicht. Also ab sofort nur noch stty -F /dev/ttyUSB0.
Zitat
Ob es eine gute Wahl ist, die Sonderzeichen in ihrer Funktion zu belassen...
...ich nutze keine Sonderzeichen. Ist alles hex was ich sende. Siehe das Beispiel ganz unten
Zitat
Zitat
Ein zweites Konsolenfenster bei seriellen Schnittstellen zu öffnen ist meistens keine gute Idee. Es kann nur ein Programm Daten empfangen. Das Programm, dass die Daten zuerst - im wahrsten Sinne des Wortes - heraus liest, lässt einem anderen Programm keine Möglichkeit mehr, die gleichen Daten erneut zu lesen. Genauso macht es keinen Sinn, wenn mehrere Geräte über die gleiche Schnittstelle gleichzeitg senden. Der Empfänger bekommt zwar alles mit, es kommt aber nur Bandsalat an.
Danke für den Hinweis. Wie oben erwähnt, ging es aber mit dem zweiten Fenster vor dem Reboot - wenn auch u.U. nur mit Glück Ich kann aber hinter dem Sendebefehl ja noch ein "&& cat < /dev/ttyUSB0" anhängen. Dann isses in einem Fenster.
Zitat
Zitat
Wozu diese ganzen Freigabe-Versuche? Pure Verzweiflung?
ABSOLUT
Zitat
Zitat
Wie hast Du die serielle Schnittstelle eingerichtet?
mittels stty -F /dev/ttyUSB0 speed 9600 cs8 cstopb -parenb. Ich war der Meinung, dass ich vor dem Reboot auch nicht mehr gemacht habe :s
Zitat
Zitat
Zitat
Welches RPi-Modell, welches Betriebssystem, welche Betriebssystemversion?
Im Moment steckt es nicht am Pi, sondern am PC: Linux debian 3.16.0-4amd64 #1 SMP Debian 3.16.36- 1+deb8ul (2016-09-03) x86_64GNU/Linux.
Mit dem Debian wird es getestet.
Zitat
Hast Du mal Programme wie cuteCom oder minicom ausprobiert, um Dir anzeigen zu lassen, wer was sendet oder empfängt?
Wie oben geschrieben, funktionierte ja vor dem Reboot alles ohne minicom & co...
Zitat
Wahrscheinlich sind dort noch Sonderzeichen aktiv, die der Sender sendet, mit denen das Kartenlesegerät nicht anfangen kann - und dann auf einen korrekten Satz wartet. Daher musst Du herausfinden, welche Bytes genau gesendet werden müssen, um eine gewünschte Aktion auszulösen. Diese Bytes musst Du dann senden (können) und alle weiteren Sachen (wie echos) ausschalten. Sonst kommt auch nur Bandsalat.
Auch schon wie oben. Ich sende lediglich in hex. Das kam vorm Reboot auch an und wurde mit "06" bzw "15" bestätigt. Das Senden sieht so aus:
echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x03' > /dev/ttyUSB0
ergibt als Rückantwort auf den zweiten geöffnetem Terminalfenster: 15, also NCK
und
echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x01' > /dev/ttyUSB0
ergibt als Rückantwort auf den zweiten geöffnetem Terminalfenster: 06, also ACK.
Ach ja, das Gerät heißt "REA T6 retail".