keine Antwort vom seriellen Port

  • Folgendes Problem:
    Ich habe am Pi über USB/RS232 ein Kartenlesegerät hängen. Dieses läuft mit 9600 Baud, 8N2. Ansprechbar ist dies über /dev/ttyUSB0. Ich habe eine gefühlte Ewigkeit gefummelt, um mit im Netz gefundenen Anleitungen vom Gerät eine Antwort zu bekommen. Bisher ohne Erfolg.

    Senden funktioniert soweit, glaube ich. Jedesmal wenn ich etwas zum Gerät sende, leuchtet auf dem Display unter dem Telefonicon "a32de" auf. Vor dem Senden habe ich "stty -F /dev/ttyUSB0 speed 9600 cs8 cstopb -parenb" gemacht. Der Befehlt "stty" gibt mir folgendes zurück:

    Code
    speed 9600 baud; line = 0;
    eol = M-^?; eol2  = M-^?; swtch = M-^?;

    Der erweiterte Befehl "stty -a -F /dev/ttyUSB0" zeigt mir u.a.: "cstopb -parenb". Das wäre ja richtig. Jedoch zeigt der Befehl "stty -a" (also ohne -F /dev/...)
    "-cstopb -parenb". Welche stimmt denn nun?

    Zum Abfragen habe ich ein zweites Konsolenfenster geöffnet. Dort lausche ich mittels "cat < /dev/ttyUSB0" auf irgend einen Eingang (hab auch schon "od -x < /dev/ttyUSB0" gestestet). Jedoch kommt nichts zurück :(

    Aus Verzweiflung habe ich jetzt "chmod 777 /dev/ttyUSB0" gemacht. In der entsprechenden Gruppe "dialout" habe ich mich auch hinzugefügt (dialout:x:20:noobee,root). Hab auch jedem zugriff gewährt mittels "chmod a+rw /dev/ttyUSB0". Mehr ist mir an Freigaben nicht eingefallen.

    Jemand noch ne Idee, warum ich keine Antwort vom Gerät bekomme`?

    Einmal editiert, zuletzt von noobee (30. Oktober 2016 um 04:31)

  • Hallo noobee,

    Folgende Fragen habe ich, bevor man Dir gezielt weiterhelfen kann:

    • Was macht Dich sicher, dass /dev/ttyUSB0 das richtige Device ist?
    • 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?
    • Ob Senden funktioniert, weißt Du auch nicht wirklich?
    • Da Du nichts weiter zum Kartenlesegerät geschrieben hast, kann ich nur allgemeine Vermutungen anstellen: Hast Du darauf geachtet, dass über GPIO-Pins RX nur maximale Pegel von 3,3 V eintrudeln dürfen - über USB nur 5 V?
    • 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.
    • Ob es eine gute Wahl ist, die Sonderzeichen in ihrer Funktion zu belassen, kann ich nicht beurteilen. Ich schalte die normalerweise alle aus, bevor ich mich einem unbekannten Gerät nähere. Aber da muss Dir die Dokumentation zum Kartenlesegerät weiterhelfen.
    • 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.
    • Wozu diese ganzen Freigabe-Versuche? Pure Verzweiflung?
    • Wie hast Du die serielle Schnittstelle eingerichtet?
    • Welches RPi-Modell, welches Betriebssystem, welche Betriebssystemversion?
    • Hast Du mal Programme wie cuteCom oder minicom ausprobiert, um Dir anzeigen zu lassen, wer was sendet oder empfängt?



    Jemand noch ne Idee, warum ich keine Antwort vom Gerät bekomme`?


    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.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (30. Oktober 2016 um 09:11)

  • Servus noobee,


    ...
    [*]Wie hast Du die serielle Schnittstelle eingerichtet?
    [*]Welches RPi-Modell, welches Betriebssystem, welche Betriebssystemversion?
    [*]Hast Du mal Programme wie cuteCom oder minicom ausprobiert, um Dir anzeigen zu lassen, wer was sendet oder empfängt?

    das wird wohl, wie so oft, wieder daran liegen, dass die rs232 nicht "freigeschaltet" ist ( -> click <- ) ...
    Und dann, wie Andreas schon anmerkte, mal mit minicom ausprobieren ...

    cu,
    -ds-

  • 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 :bravo2:

    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 :no_sad:

    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 :rolleyes: 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 :wallbash:

    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 :daumendreh2: :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:

    Code
    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

    Code
    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".

  • Hallo noobee,

    Danke für Deine Antworten. Diese provozieren neue Fragen und Anregungen.

    Wie hast Du die serielle Schnittstelle eingerichtet? Du musst ein, zwei Konfigurationsdateien ändern / über raspi-config ändern lassen. Beschreibe bitte genau, was Du da wie gemacht hast. Und poste bitte auch die beiden Dateien, die durch raspi-config berührt wurden. Und bitte kein Tutorial verlinken. Ich will wissen, WAS DU GENAU gemacht hast.
    ==> Bääh! Du arbeitest ja mit USB...

    Du überträgst

    Code
    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

    Code
    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.

    Das sind für mich (fast) alles Sonderzeichen. Denn die "echten" Zeichen = druckbaren Zeichen fangen erst bei 0x20 an. Die serielle Schnittstelle misst also diesen Zeichen eine funktionale Bedeutung bei. Was dazu führt, dass eine nicht vorhandene Hardware angesteuert wird, irgendwelche Timer gesetzt werden etc. So tief gehe ich da jetzt nicht in Deine Bytes hinein.

    Poste bitte mal die Ausgabe von

    Code
    stty -F /dev/ttyUSB0 -a


    Und dann gehen wir gemeinsam Sinn und Unsinn der stty-Ausgabe durch und Du entfernst dann bitte alle hinderlichen Parameter.

    Vorab kannst Du Dich über

    Code
    man stty

    erkundigen, was es da so alles gibt.

    Für ein Projekt hatte ich auch die serielle Schnittstelle zur Datenübertragung nutzen müssen, damit ein Raspberry Pi mit drei Controllern kommunizieren kann. Das war ein Akt, bis die stty-Parameter standen. Und selbst Monate später, als jeder davon ausging, dass nach wochenlangen Testläufen alle denkbaren Byte-Kombinationen tausendfach durchgenudelt wurden, gab es dann einen Ausfall, der auf einen nicht optimalen stty-Parameter hindeutete.

    Wenn die Parameter alle richtig gesetzt sind, dann kannst Du diese über stty speichern und beim Neustart wieder für /dev/ttyUSB0 laden. Dann läuft es immer wieder reproduzierbar.



    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 :bravo2:


    Das sagt mir: Sonderzeichen werden von der Schnittstelle Funktionen zugeordnet, Funktionen werden durchgeführt, Bytes werden nicht übertragen.
    Also: stty-Parameter analysieren und anpassen!


    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 :no_sad:


    Deswegen machen wir das jetzt auf die Brecheisen-Methode - und speichern dann den Krempel.


    ...ich nutze keine Sonderzeichen. Ist alles hex was ich sende. Siehe das Beispiel ganz unten


    Siehe oben. Du nutzt Sonderzeichen < 0x20 en masse...


    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.


    Da wird's genauso laufen.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (30. Oktober 2016 um 20:47)

  • ok, erstmal die Ausgabe von "stty -F /dev/ttyUSB0 -a":


    Code
    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
    -parenb -parodd -cmspar cs8 hupcl cstopb cread clocal -crtscts
    -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
    -iuclc -ixany -imaxbel -iutf8
    opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
    echoctl echoke

    ls -la /dev/ttyUSB0

    Code
    crw-rw-rw- 1 root dialout 188, 0 Okt 30 19:38 /dev/ttyUSB0

    Einmal editiert, zuletzt von noobee (30. Oktober 2016 um 21:23)

  • Hallo noobee,

    das sieht ja allerliebst aus... Danke!

    Dann schauen wir uns mal die Sonderzeichen an.

    Deine serielle Schnittstelle reagiert auf einen Interrupt ^C. Das heißt, wenn dieser Code = ETX "End of Text" kommt, dann wird dieser Code nicht durchgelassen sondern bewirkt irgendeine Aktion. Das heißt, ETX kommt niemals an. Willst Du das so? Dann lasse diese Einstellung, willst Du es nicht, dann lösche dieses Zeichen.

    Code
    man stty

    sagt Dir, was Du machen musst, um diese und andere Sonderzeichen zu entfernen, d.h. bei der Übertragung ohne Hardware-Einfluss durchzulassen.


    Das Gleiche für Quit ^\. Belassen, wenn Hardware darauf reagieren soll - löschen wenn das Zeichen FS = File Separator übertragen werden soll

    Kurzum, ich würde erase, kill eof, eol (ist schon), ..., start, stop, susp und rprnt, werase, lnext, flush auf <undef> setzen.

    Setze das bitte mal um und berichte von der Änderung / Verbesserung.

    Fortsetzung folgt...


    Im zweiten Ansatz deaktivierst Du alle echos: -echo, -echoe, -echok, -echonl, -echoctl, -echokl
    Setze das bitte mal um und berichte von der Änderung / Verbesserung.


    Fortsetzung folgt...


    3. Ansatz (das war jetzt echt anstrengend :geek: :(
    Alle anderen Parameter so lassen - außer folgenden Änderungen:

    Bitte auch dieses umsetzen, durch

    Code
    stty -F /dev/ttyUSB0 -a

    überprüfen, dass alle Einstellungen wie von mir empfohlen, umgesetzt sind. Dann bitte die Datenübertragung prüfen und berichten, ob es klappt - oder was noch nicht läuft.


    Die Einstellungen für Baudrate, Anzahl der Datenbits und Stopbits sowie Parität hast Du abgeglichen, dass hierüber bei beiden Teilnehmehmern die gleichen Vorstellungen bestehen?


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (30. Oktober 2016 um 22:40)

  • EDIT: 3. Ansatz hab ich zu spät gesehen. mach ich mal

    Ach du sch***. Das sieht eher nicht so einfach aus :s Ok... hilft ja nix :bravo2:

    Zitat

    Deine serielle Schnittstelle reagiert auf einen Interrupt ^C. Das heißt, wenn dieser Code = ETX "End of Text" kommt, dann wird dieser Code nicht durchgelassen sondern bewirkt irgendeine Aktion. Das heißt, ETX kommt niemals an. Willst Du das so? Dann lasse diese Einstellung, willst Du es nicht, dann lösche dieses Zeichen.


    Richtig, es wird mit jedem "Hex-String", den ich sende, auch ein EXT mitgesendet. Und zwar in der Form \x10\x03. Wobei \x10 = DLE und die \x03 = EXT. ABER danach schicke ich noch ein High- und ein Low-Level-Bit mit als Prüfsumme. Es darf also nach EXT nicht abbrechen. Laut "stty man" setze ich also:

    -brkint (breaks cause an interrupt signal)

    Der Rest ist ja recht fix mit stty negiert.

    Code
    erase, kill eof, eol (ist schon), ..., start, stop, susp und rprnt, werase, lnext, flush auf <undef> setzen.
    -echo, -echoe, -echok, -echonl, -echoctl, -echokl

    Ok, neues "-a" ergibt:

    Soo, ein erneutes Senden über shell:

    Code
    echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x01' > /dev/ttyUSB0


    brachte nix. Das Gerät blinkt kurz. Es kommt also was an. Rückmeldung gibts aber nicht. Auch das "a32de" kommt immer noch nicht wieder :blush:

    Einmal editiert, zuletzt von noobee (30. Oktober 2016 um 22:40)

  • Hallo noobee,


    EDIT: 3. Ansatz hab ich zu spät gesehen. mach ich mal


    Ok, neues "-a" ergibt:

    Ist die stty-Ausgabe jetzt die von nach dem 2. oder 3.Ansatz? Wenn Letzteres, dann sind da einige Einstellungen nicht wie empfohlen. Kannst Du das nochmal prüfen und ändern?


    Soo, ein erneutes Senden über shell:

    Code
    echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x01' > /dev/ttyUSB0


    brachte nix. Das Gerät blinkt kurz. Es kommt also was an. Rückmeldung gibts aber nicht. Auch das "a32de" kommt immer noch nicht wieder :blush:

    Edit: Setze bitte noch min auf 1 und time auf 1.

    Ist eine Besserung eingetreten?

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (30. Oktober 2016 um 22:59)

  • Alle empfohlenen Änderungen eingearbeitet. Mit -noflsh und noflsh getestet. Ohne Erfolg, keine Besserung. Ich hab auch mal mein brkint und -brkint getestet, zusammen mit noflsh und -noflsh. Keine Besserung :no_sad:

    Einmal editiert, zuletzt von noobee (30. Oktober 2016 um 23:02)

  • Hallo Noobee,

    dann setze bitte noch intr und quit jeweils auf <undef>.

    Dann ist da ein Parameter, die Du bitte prüfen solltest, ob das Verhalten so beabsichtigt ist:
    cstopb: bedeutet 2 Stopbits, ist sehr ungewöhnlich, im vorigen Beitrag hatte ich Dir -cstopb empfohlen.

    Wenn es dann immer noch nicht funkioniert, dann geht's Morgen weiter =( .

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • So, nochmal kurz das Herz stehen geblieben :-/ Aber hat doch gepasst:

    dmesg

    Code
    [19598.955673] usb 1-1.4: pl2303 converter now attached to ttyUSB0
    Code
    [color=#333333]dann setze bitte noch intr und quit jeweils auf <undef>[/color]


    unverändert, keine Ergebnisse. Auch nicht mit -cstopb für 1 Stopbit

    Edit:
    Ok, nach langem Probieren vllt. ein kleiner Erfolg. Mittels "stty sane" hab ich erst mal wieder alles in eine Art Standard zurück versetzt (sane: sets all modes to reasonable values).

    Code
    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
    parenb -parodd -cmspar cs8 -hupcl cstopb cread clocal -crtscts
    -ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
    -iuclc -ixany imaxbel -iutf8
    opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
    echoctl echoke


    Jetzt kommt wieder dieses "a32de" auf dem Display. Also scheint ja irgend was anzukommen. Zurück kommt aber noch nix. Des weiteren habe ich im Netz einen Flyer von Gerät gefunden. Leider stand nix verwertbares drin außer: 9600 Baud, 8 Datenbit, 2 Stoppbit, keine Parität.
    Was hat es denn mit stty sane, stty raw, stty cooked auf sich??

    Noch ne Frage außer der Reihe. Wie sende ich in nem sh-script meinen String? So geht es leider nicht:

    Code
    echo '-en "\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x02"' > /dev/ttyUSB0

    Einmal editiert, zuletzt von noobee (31. Oktober 2016 um 05:22)

  • Hallo noobee,


    Jetzt kommt wieder dieses "a32de" auf dem Display. Also scheint ja irgend was anzukommen. Zurück kommt aber noch nix. Des weiteren habe ich im Netz einen Flyer von Gerät gefunden. Leider stand nix verwertbares drin außer: 9600 Baud, 8 Datenbit, 2 Stoppbit, keine Parität.


    8 Datenbit ==> cs8
    2 Stopbits ==> cstopb
    keine Parität ==> -parenb (-parodd oder parodd sollte egal sein, dito für ignpar)

    Dann hat das vermutlich an den Stopbits gelegen. Ich ging da gestern noch von einem einzigen aus.


    Was hat es denn mit stty sane, stty raw, stty cooked auf sich??

    sane & Co. setzen viele der einzeln setzbaren Parameter auf jeweils vorgegebene Werte. Es handelt sich dabei also um verschiedene Parametersätze. Welche Parameter davon beeinflusst werden, sagt Dir auch wieder

    Code
    man stty


    Noch ne Frage außer der Reihe. Wie sende ich in nem sh-script meinen String? So geht es leider nicht:

    Code
    echo '-en "\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x02"' > /dev/ttyUSB0


    So nicht, aber entweder

    Code
    echo -en "\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x02" > /dev/ttyUSB0


    oder so

    Code
    echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x02' > /dev/ttyUSB0

    Das hattest Du aber gestern schon richtig angegeben. ;)

    Ich gehe dann nochmal tiefer in die einzelnen Parameter - vielleicht fällt mir noch irgendwas auf. Ich vermute weiterhin, dass ein Zeichen aufgrund der Parameter-Definition nicht übertragen wird oder stattdessen ein anderes. Und dem Empfänger dann kein vollständiger Datensatz vorliegt oder kein richtiger. In allen diesen Fällen erfolgt keine Rückmeldung, auf die Du wartest.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (31. Oktober 2016 um 10:31)

  • Code
    8 Datenbit ==> cs8
    2 Stopbits ==> cstopb
    keine Parität ==> -parenb (-parodd oder parodd sollte egal sein, dito für ignpar)


    Sehr gut, ist gesetzt :thumbs1:

    Code
    Dann hat das vermutlich an den Stopbits gelegen. Ich ging da gestern noch von einem einzigen aus.


    Naja, wenn das eigentlich der Standard ist, war es ja ok :bravo2:

    Nur so am Rande: Meine test.sh geht nicht. Weder

    Code
    echo -en '\x10\x02\x06\x00\......\x10\x03\xD3\x01' > /dev/ttyUSB0

    noch

    Code
    echo -en "\x10\x02\x06\x00\......\x10\x03\xD3\x01" > /dev/ttyUSB0

    Aber das soll hier nicht das Problem werden. Ich mach einen neuen dafür auf :s

    Code
    Ich gehe dann nochmal tiefer in die einzelnen Parameter - vielleicht fällt mir noch irgendwas auf. Ich vermute weiterhin, dass ein Zeichen aufgrund der Parameter-Definition nicht übertragen wird oder stattdessen ein anderes. Und dem Empfänger dann kein vollständiger Datensatz vorliegt oder kein richtiger. In allen diesen Fällen erfolgt keine Rückmeldung, auf die Du wartest.


    Ich kann dir alle Parameter bei meinem "Hex-String" genau erklären:
    \x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x02

    \x10 =DLE
    \x02 = StartText
    \x06 = BeginnRegistrierung
    \x00 = BeginnRegistrierung-Unterpunkt
    \x0E = 14 - Länge der folgenden Nachricht inkl. Passwort (habs mal unterstrichen)
    \x10 =DLE
    \x03 = EndText
    \xD3 = Prüsummenbit High
    \x02 = Prüfsummenbit Low

    Vielleicht hilfts ja irgendwie weiter :danke_ATDE:

    Einmal editiert, zuletzt von noobee (31. Oktober 2016 um 13:50)

  • Hallo noobee,

    So, wir kommen der Sache ein Stück näher.

    Deine Zeichenkette enthält
    - 0x03 = ETX = End of Text
    - 0x04 = EOT = End of Transmission

    Beides wäre belanglos. ABER: Diese beiden Bytes sind auch als ^C bzw. ^D bekannt. und damit haben sie in Deiner stty-Konfiguration eine besondere Bedeutung, nämlich als intr und eof. Das heißt, dass da die Übertragung endet und der Rest nicht mehr für voll genommen wird. Die Prüfsummenbits werden dann wohl nicht mehr angenommen (vermute ich jetzt mal). Damit ist der Datensatz nicht vollständig, nicht valide. Ein Rückmeldung (ACK oder NAK) erfolgt dann auch nicht mehr.

    Wird's besser, wenn Du intr und eof jeweils auf <undef> setzt?

    Ansonsten kannst Du noch mit den Parametern
    - min (entspricht der Anzahl der zu übertragenden Zeichen): Das wäre hier jetzt 23. Handelt es sich eigentlich immer um die gleichen Daten?
    - time (entspricht timeout in Zehntel Sekunden): Eigentlich ist hier 1 mehr als ausreichend.

    Und schließlich: Du bist Dir sicher dass die Prüfsummenbytes korrekt angegeben sind?

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (31. Oktober 2016 um 19:13)

  • Code
    Wird's besser, wenn Du intr und eof jeweils auf <undef> setzt?


    Nein, das ändert nichts. Kommt nichts zurück, bzw an.

    Code
    Und schließlich: Du bist Dir sicher dass die Prüfsummenbytes korrekt angegeben sind?


    Ja. Also bei dem "Hex-String"
    \x10\x02\x06......\x10\x03\xD3\x02 sollte ein NAK (15) zurück kommen und bei
    \x10\x02\x06......\x10\x03\xD3\x01 ein ACK (06).
    "06" ist also eine korrekte Nachricht mit korrekter Prüfsumme, "15" ist eine korrekte Nachricht mit falscher Prüfsumme. Syntaktisch sind aber beide korrekt.

    Ich zieh nochmal den USB raus und teste mal die Geschichten stty sane, stty cooked und stty raw durch. Irgendwas muss doch gehen :no_sad: :no_sad:


    EDIT: Ich fasse es nicht. Der Befehl stty -F /devttyUSB0 raw funktioniert. Damit kann ich meinen "Hex-String" senden. Dieser kommt an. Jetzt muss ich nur noch schauen, wie ich mit "cat" meine "06" bzw "15" ordentlich in eine Datei speichern kann. Im Screens sieht man, dass wohl erst mal nicht verarbeitbares Zeug zurück kommt...

    Achja, mal die Einstellungen, welche "stty -F /dev/ttyUSB0 raw" gesetzt hat:

    Code
    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
    -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
    -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
    -iuclc -ixany -imaxbel -iutf8
    -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    -isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
    echoctl echoke
  • Hallo noobee,


    EDIT: Ich fasse es nicht. Der Befehl stty -F /devttyUSB0 raw funktioniert. Damit kann ich meinen "Hex-String" senden. Dieser kommt an. Jetzt muss ich nur noch schauen, wie ich mit "cat" meine "06" bzw "15" ordentlich in eine Datei speichern kann. Im Screens sieht man, dass wohl erst mal nicht verarbeitbares Zeug zurück kommt...

    :bravo2: :s

    Für mich fast nicht nachvollziehbar. Aber egaal, Hauptsache, es funktioniert jetzt.


    Achja, mal die Einstellungen, welche "stty -F /dev/ttyUSB0 raw" gesetzt hat:

    Code
    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
    -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
    -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
    -iuclc -ixany -imaxbel -iutf8
    -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    -isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
    echoctl echoke

    Ich würde mal das Programm cuteCom installieren. Damit kannst Du Hex-Codes an die serielle Schnittstelle senden und die Rückmeldung ebenso als Hex-Code anzeigen lassen. Dann siehst Du direkt ob 0x06 oder 0x15 zurückkommt. Und Du siehst auch, was noch so alles übertragen wird.

    Offenbar wird hier mehr als nur ein Byte geantwortet. Als Ursache vermute ich da als Erstes die wiedereingeführten Echos. Die würde ich mal jeweils einzeln deaktivieren und schauen, was sich da auswirkt.
    Die Echos sind irgendwie irre. Da werden Auszüge bereits gesendeter Datensätze wiederholt. Längst Vergangenes kommt wieder hoch. Wie im richtigen Leben.
    Aber hier stört es.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (1. November 2016 um 23:53)

  • Zitat

    Für mich fast nicht nachvollziehbar. Aber egaal, Hauptsache, es funktioniert jetzt.


    Ja und nein. Schön, dass das Gesendete ankommt. Blöd ist jetzt, dass ich nicht weiß, welche der Parameter gesetzt sein müssen und welche nicht. Sicher könnte ich jetzt mit ner Schleife alle Parameter mit und ohne "-" testen... Naja.

    Zitat

    Ich würde mal das Programm cuteCom installieren. Damit kannst Du Hex-Codes an die serielle Schnittstelle senden und die Rückmeldung ebenso als Hex-Code anzeigen lassen. Dann siehst Du direkt ob 0x06 oder 0x15 zurückkommt. Und Du siehst auch, was noch so alles übertragen wird.


    Des wird gemacht. Mal sehen, was da so für Bandsalat zurück kommt... Ich könnte doch aber sicher auch mit den "echo-Parametern" spielen, oder? Sind die nicht für die Rückgabe zuständig?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!