Datenübertragung über UART fehlerhaft

  • Grüßt euch,


    Fehlerbeschreibung:
    ich versuche mich derzeit mit der Seriellen Schnittstelle einzuarbeiten. Beim Empfangen funktioniert alles ohne Probleme, nur wenn der Raspberry manuell Daten Übertragen soll, sendet er Teilweise wirres Zeug.

    Beispielhaft:

    • 9600 Baud Funktioniert ohne Probleme
    • 19600 Baud kommen nur wirre Zeichen
    • 115200 Baud erscheint ein Zusätzliches Zeichen beim Start


    Wenn ich die Software Minicom benutze gibt es nicht einen solchen Fehler.

    Fehlerursache:
    Die Ursache des Fehlers ist eine vorangehendes 32us Sekunden langes Signal, wodurch das Zielsystem die Signale falsch Interpretiert

    Edit: Das Signal ist immer 32us lang, auch wenn die Baudrate geändert wird. Was eigentlich nicht zur Datenübertragung passt.

    Siehe:

    Aufbau:(Raspberry B+)
    Der Fehler ist ebenfalls zusehen wenn ich mit dem Oszilloskop direkt die IO Ports prüfe. Sonnst ist noch ein Max3232 dazwischen geschaltet und mit dem PC verbunden.

    Das Signal wird mit den folgenden Oszilloskop gemessen: http://www.datatec.de/Keysight-MSO6034A-Oszilloskop.htm

    Derzeitige Einstellungen und Vorgehensweisen:

    Ich habe /boot/cmdline.txt wie in den Tutorialen angepasst:
    von

    Code
    dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblkop2 rootfstype=ext4 $evator=deadline rootwait

    in dieser Zeile geändern:

    Zitat

    dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblkop2 rootfstype=ext4 $evator=deadline rootwait

    in /etc/inittab habe ich die Zeile auskommentiert:

    Code
    #Spawn a getty on Raspberry Pi serial line
    #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

    Die Berechtigung für den User habe ich gesetzt:

    Code
    sudo usermod -a -G dialout sysop
    sudo usermod -a -G tty sysop

    und die geschwindigkeit für die Schnittstelle Vorgegeben(Parity, Stopbit und ähnliches passen alles):

    Code
    sudo stty 115200 -F /dev/ttyAMA0
    Code
    sysop@pipaos:~$ stty -F /dev/ttyAMA0 -a
    speed 115200 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 = 5;
    -parenb -parodd 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

    Die Ports sind nicht weiter in anderen Programmen konfiguriert und der Fehler tritt über die Shell oder C Programmierung auf.
    z.B. mit dem Befehl:

    Code
    echo hallo >> /dev/ttyAMA0


    Lösung?
    Hat jemand Lösungsvorschläge?

    Edit:
    Der Grundzustand mit stty sane
    hilft auch nicht weiter

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

    Einmal editiert, zuletzt von DeFisch (16. Oktober 2014 um 14:13)

  • Aus welchem Tutorial hast du die cmdline.txt Einstellungen?
    Der Eintrag $evator=deadline ist imho fehlerhaft und sollte eigentlich elevator=deadline lauten. Siehe dazu: http://elinux.org/RPi_cmdline.txt

    Wie ist denn die Schnittstelle von der Gegenstelle eingestellt?


  • Aus welchem Tutorial hast du die cmdline.txt Einstellungen?
    Der Eintrag $evator=deadline ist imho fehlerhaft und sollte eigentlich elevator=deadline lauten. Siehe dazu: http://elinux.org/RPi_cmdline.txt

    Das war durch die Standardinstallation von Pipaos vorgegeben. Werde ich natürlich anpassen, da es fehlerhaft ist.
    Edit da der Pi danach gar nicht mehr starten wollte, habe ich mir die Werte hiervon geholt (http://www.hobbytronics.co.uk/raspberry-pi-serial-port) und werde es testen

    Code
    dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
    Zitat


    Wie ist denn die Schnittstelle von der Gegenstelle eingestellt?

    Die Einstellung von Hterm sollte man auf den Bild erkennen können. Aber das sollte irrelevant sein, da dieser Impuls auch auf den Oszi zusehen ist, wenn man dies direkt mit den Pi verbindet. (Das Oszi ist Ebenso auf die 115200 Baud wie der RPI eingestellt.)

    Jetzt noch einmal der Impuls ist immer zusehen. Sei es bei 19200, 57600 oder 115200 Baud und ist in jeder Konfiguration 32us lang(Wenn es eigentlich Daten sein sollten, sollte sich die Impulslänge mit ändernder Baudrate anpassen)

    Bei 19200 Baud sind solangsam das er den Impuls noch als Teil des eigentliches Byts sieht und deswegen die eigentlichen Daten verschiebt und es nur mist herauskommt.

    Edit: Nach dem Änderung der Zeile tritt der Fehler ebenso auf.
    Die Parameter von Hterm sind Baud 115200 Data 8 Stop 1 Parity none

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

    Einmal editiert, zuletzt von DeFisch (16. Oktober 2014 um 15:17)

  • ER hatte danach Probleme beim Booten und hing sich dann nach 7 Sekunden auf, wo dann die Fake Hardwareclock gestartet wird. d.h. die ersten Programme gestartet werden sollte von der Shell 8|

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

  • Moment ... jetzt komme ich gerade nicht mehr mit ... :s
    Zuerst ist es ein Problem mit dem UART - und jetzt sind es Probleme beim booten?
    Kann es sein, dass Du vielleicht kein Netz hast?
    Hast Du da mal logs, screenshots ...
    Und wie hängt das jetzt mit der UART-Problematik zusammen?

    Bin gerade etwas verwirrt,
    -ds-

  • Meigraf, hat mich darauf aufmerksam gemacht das meine /boot/cmdline.txt fehlerhaft war. Nach dem Korrigieren ist der Pi aber nicht mehr vollständig gestartet. Nachdem ich die Informationen von der Webseite genommen hatte und per Windows geändert habe, geht es aber wieder. Deswegen sagte ich das dort ja noch was anderes Das hat jetzt nix mit den Uart Problem zutun.

    Wenn du Logs haben möchtest, musst du mir aber bitte sagen welche.

    Das Netz geht soweit, ich kann über Wget Daten aus dem Internet herunterladen.

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

    Einmal editiert, zuletzt von DeFisch (16. Oktober 2014 um 16:25)

  • Also fährt der RPi jetzt anstandslos hoch ...
    Jetzt noch mal zum UART Problem:
    Wenn ich das richtig verstanden habe, dann kommt also ein "Extra-Zeichen" ...

    Wann?
    Direkt beim booten?
    Oder einmal, wenn Du eine Verbindung herstellst
    oder jedesmal, wenn Du eine Verbindung herstellst?

    cu,
    -ds-

  • Ja der Pi startet jetzt anstandslos.

    Das Extra Zeichen erscheint nur bei 115200 oder 57600 Baut, weil der Abstand zwischen dem Impuls und der nachfolgenden Datenübertragung groß genug ist und es als extra Zeichen Interpretiert wird.
    Wenn ich die Datenraten kleiner und längere Signale einstelle z.b. 19200 Baud, dann wird der Impuls zu den den ersten eigentlichen Bit dazugezählt und die eigentlichen Nutzdaten scheinen sich zu verschieben. Dadurch erhalte ich nur noch falsche Werte.

    Der Fehler tritt bei jeder Datenübertragung(senden vom Pi, empfangen geht) auf, die ich nicht mit Minicom starte.

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

  • Mit welchem Programm bzw. in welcher Sprache ist die Software verfasst, mit der Du die Daten überträgst?
    Es gibt da z.B. bei C-Programmen das Problem, dass ein tcsetattr() einen positiven Rückgabewert liefert, auch wenn nicht alle Parameter gesetzt werden konnten.

    cu,
    -ds-

  • Shell ... mag sein, aber imho uninteressant.
    Wie setzt Du die Parameter? Hast Du mal verifiziert, ob auch alle Werte richtig gesetzt sind - vor allem die Baudrate?
    Wie schon erwähnt gibts hier bei z.B. tcsetattr() eine Falle ... in die bin ich auch schon getappt und hab' daraufhin halt herausgefunden, was schief läuft ...

    //EDIT: Den Effekt, dass der eine oder andere Wert bei tcsetattr() unterschlagen wird, hatte ich bisher unter Unix/Linux übrigens nie - das erste mal auf dem RPi :fies:


    cu,
    -ds-

  • Die Baud Werte sind richtig gesetzt das konnte ich mit dem Oszilloskop verifizieren. Die anderen Fragen kann ich erst am Montag auf arbeit beantworten.
    Danke für die Hilfen.

    dennoch finde ich das seltsam das Problem bei der Programmierung zusuchen, wenn der kleinste Nenner die Shell Befehle nicht funktionieren, aber dennoch werde ich am Montag mein Beispielprogramm posten.

    Danke noch einmal

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

  • Guten Morgen,

    wie versprochen gibt es hier mein Beispielcode:

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

    Einmal editiert, zuletzt von DeFisch (20. Oktober 2014 um 08:25)

  • Moin moin,


    ...

    Code
    ...
         if (tcsetattr(fd, TCSAFLUSH, &options) != 0) return(-1);  
    ...

    Wie schon vorher mal erwähnt:

    Zitat


    Note that tcsetattr() returns success if any of the requested changes could be successfully carried out. Therefore, when making multiple changes it may be necessary to follow this call with a further call to tcgetattr() to check that all changes have been performed successfully.


    (kann -> hier <- nachgelesen werden)

    Bau doch einfach mal einen check auf die tatsächlich gesetzte Baudrate ein - also einen tcgetattr() - und setz die Baudrate ggf. noch einmal.
    Du wirst sehen ... da liegt der Hase im Pfeffer ...
    Am sinnvollsten wäre halt ein Umbau der gesamten Logik - ich hab' da halt eine Prüffunktion dazu gebastelt und das setup so umprogrammiert, dass es auch mehrmals hintereinander ausgeführt werden kann.
    Bisher hat nach dem ersten tcsetattr() allerdings nur die Baudrate nicht gepasst ... beim zweiten tcsetattr() war dann alles ok.

    cu,
    -ds-

  • Danke für die Informationen. In der Software konnte ich den Misstand mit der Baudrate erkennen. Mit cfgetospeed() /cfgetispeed kann ich die Problematik nachvollziehen und nach dem 2. setzen der Baudrate wird diese danach auch angezeigt und danach sende ich dann erst die Daten.

    Leider stimmen die übertragenen Daten Werte immer noch nicht überein und es ergibt sich noch das gleiche Fehlerbild wie am Anfang.

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

  • Hi,
    da wirst Du wohl ein wenig rumexperimentieren müssen.
    Evtl. stimmen dann auch andere Werte nicht.
    Hast Du als Ausgangspunkt für die Paramter schon mal einen setraw() probiert und anschliessend nur Baudrate, Parity, Stopbits und Datenbits gesetzt?

    Wie gesagt, muss imho in der Ecke liegen, da minicom je funktioniert ...

    cu,
    -ds-

  • Also ich habe jetzt recht viel herum experimentiert und getestet welche Einstellungen ich wegnehmen kann und die Nachrichten noch ankommen.
    Eher aus Zufall, habe ich zum Spaß habe ich einen anderen Filedeskriptor z.B. 1 Übergeben, womit meine ganzen Settings ja eigentlich hinfällig sind. Dabei ist mir aufgefallen das bei mir aus dem Grund keine Daten übertragen werden konnten(soweit verständlich), aber über den Uart dennoch einen kurzen einzelnen Impuls von 32us Sekunden gibt, welcher wieder als #FF Interpretiert wird.

    setraw() werde ich mir jetzt einmal anschauen.

    Edit: es ist schon einmal schön das anscheinend andere das gleiche Problem haben(letztes Kommentar), die Lösung hilft bei mir leider nicht(ich habe auch schon sein Versuch ausprobiert)

    ein Traum ist unerlässlich wenn man die Zukunft gestalten will

    Einmal editiert, zuletzt von DeFisch (20. Oktober 2014 um 13:20)

Jetzt mitmachen!

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