serielle Kommunikation Arduino Pro Mini -> RPi Uart

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • serielle Kommunikation Arduino Pro Mini -> RPi Uart? Schau mal ob du hier fündig wirst!

  • Sorry, aber das ist UART1 ... ganz normaler Hardware UART

    Liest Du Dir die Links eigentlich durch, die Du selber postest? Da steht genau das drin, was ich oben beschrieben haben, inklusive der overlays um den AMA0 wieder zurückzubiegen.

    ich würde ja fast wetten, dass die meisten Probleme mit dem mini-UART durch den komischen Kauz vor dem Bildschirm selbst verursacht sind.

    Klar, alle blöd ausser Dir. Selbst die Raspi-Macher sind zu blöd und diskutieren hier über Lösungsansätze zu einem völlig überflüssigen Bugreport: https://github.com/raspberrypi/firmware/issues/553

    Nur weil Du keine Probleme damit hast, heisst das nicht, dass andere auch keine Probleme damit haben können.

  • Moin ossihmz,

    sri für die Ot-Diskussion. Manchmal ist es so.

    So, lass uns mal den Stand feststellen.

    Hast du BT ausgeschaltet?

    Du nutzt nun welche Schnittstelle?

    War der Test mit dem RX/TX-Kurzschluß erfolgreich?

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • BT ist eingeschaltet. Aber läuft über tyyAMA0. Ich gehe jetzt über tyyS0. Bei den neuen RPis ist das standardmäßig anders habe ich gelernt.


    Die Zahlen stimmen jetzt. Nur die Ausgabe ist immernoch verschoben. Manchmal sieht es gut aus und es steht in Spalten. Oft aber halt nicht.

    Mit dem seriellen Monitor via IDE passt alles.

    Standpunkt jetzt ist also: UART funktioniert. Die Daten kommen an, wenn ich minicom starte.

    Der Code ist vorerst sehr einfach. Ein Zeit Modul ist bestellt um dem ganzen einen Timestamp aufzudrücken.

    Rechnung erfolgt auch noch über IDE, sodass der RPi nur die fertigen Daten bekommt und in eine Datei speichert.

    Das einzige Problem ist nun also, in welchem Format die Daten am RPi ankommen.

    ABER die Daten sind richtig! :)

  • Moin ossihmz,

    ich halte mich nun mal raus.

    Lass den dreamshader mal weitermachen.

    Gruss Bernd und viel Erfolg

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Schmeiss mal alle  Serial.print("\t");  raus und gib' den letzten Wert mit Serial.prinln() aus ...cu,-ds-

    Kommando zurück ...

    Das passt schon.

    Da ist im Terminal-Programm was verstellt ( CR/LF Interpretation bzw. Konvertierung ).

    cu,

    -ds-

  • Solche Sprüche gehen mir tierisch auf den Zeiger, unterlass das in Zukunft! :richter:

    "ich würde ja fast wetten, dass die meisten Probleme mit dem mini-UART durch den komischen Kauz vor dem Bildschirm selbst verursacht sind."


    Solche Sprüche gehen mir tierisch auf den Zeiger. Und nu?

  • @Scharlih

    bitte nun nicht weiter machen.

    Wir wollen das Problem lösen!

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • War der Test mit dem RX/TX-Kurzschluß erfolgreich?

    Der Test mit Rx/Tx Loopback kann auch erfolgreich sein, wenn die Baudrate falsch oder daneben ist. Denn er empfängt ja mit der gleichen falschen Baudrate, mit der er sendet.

  • Den Loopback-Versuch macht man auch nicht, um die Baudrate zu überprüfen sondern um einen Hardware-Defekt auszuschliessen.

    Deshalb sollte man auch darauf achten, dass im Terminal(-Programm) das lokale Echo aus ist, weil sonst die Zeichen von der Treiberschicht zurückkommen.

    //EDIT: ossihmz spiel' mal in minicom mit CTRL+A - O - "Bildschirm und Tastatur" bei der Zeichenkonvertierung rum

    Anmerkung: in der Unix/Linux Welt ist das Zeichen \n gleichbedeutend mit dem Beginn einer neuen Zeile und wird u.a. vom Tastatur- und/oder Bildschirm-Treiber entsprechend konvertiert. Es wird also quasi ein CR (Wagenrücklauf) dazugeschummelt.

    Serial.println() schickt demzufolge auch nur ein \n ... deshalb schaltet minicom einfach nur eine Zeile weiter.

    cu,

    -ds-

  • piel' mal in minicom mit CTRL+A - O - "Bildschirm und Tastatur" bei der Zeichenkonvertierung rum

    Hallo zusammen,

    ich hab mal kurz das Zusammenspiel eines ESP und dem Pi über die serielle Verbindung probiert. Ich gebe eine zusammengestückelte Zeile (also so ähnlich wie ossihmz) mit einem abschliessenden println aus. Da ist nix verrutscht. Und ttyS0 funktioniert ebenfalls ohne Murren.

    Spoiler anzeigen

    void setup()

    {

    Serial.begin(9600);

    }

    void loop()

    {

    Serial.print("111");

    Serial.print(" - ");

    Serial.print("222");

    Serial.print(" - ");

    Serial.print("333");

    Serial.print(" - ");

    Serial.println("444");

    delay(1000);

    }

    Was habe ich gemacht?

    System raspbian lite installiert, minicom installiert. Über sudo raspi-config  die serielle Konsole ab- und die Ports angeschaltet (kommt als zweite Frage nach dem Abschalten). Pi runterfahren. ESP mit dem Pi verbunden. Neustart. Mit minicom -s minicom im Konfigurationsmodus gestartet, Parameter eingestellt. Fertig, geht.


    Edith sagt: die GND sind natürlich verbunden und 115200 funktioniert ebenfalls ohne Probleme.

    Edith2 sagt: Es ist ein Raspberry Pi3B+, der Vollständigkeit halber.

  • //EDIT: ossihmz spiel' mal in minicom mit CTRL+A - O - "Bildschirm und Tastatur" bei der Zeichenkonvertierung rum

    Anmerkung: in der Unix/Linux Welt ist das Zeichen \n gleichbedeutend mit dem Beginn einer neuen Zeile und wird u.a. vom Tastatur- und/oder Bildschirm-Treiber entsprechend konvertiert. Es wird also quasi ein CR (Wagenrücklauf) dazugeschummelt.

    Serial.println() schickt demzufolge auch nur ein \n ... deshalb schaltet minicom einfach nur eine Zeile weiter.

    Wenn ich nun println weglasse, schiebe ich die Daten komplett in einer Zeile durch. Das ist ja auch nicht das was ich brauche.

    In der Zeichenkonvertierung war der Wagenrücklauf deaktiviert. Habs geändert und jetzt gibt's die Daten zumindest in Spalten.

    Nach einer gewissen Zeit schummeln sich dann jedoch wieder ungewollte Zeilenumbrüche ein nach jedem x,y,z Wertepaar

    Es ist keine konsistente Ausgabe, die ich erzeuge. Wenn die Datei immer gleich wäre, könnte ich sie anschließend via Python Skript einlesen und derart ändern, wie ich sie benötige. Aber das funktioniert nicht, wenn die Datei immer anders aussieht.

    Wenn ich das Ganze mit minicom -C Test.txt in eine Datei schreibe, werden manchmal 2 Wertepaar hintereinander geschrieben, und erst danach erfolgt ein Zeilenumbruch.

    Ich hänge meine erzeugte Datei mal an vom RPi aus, falls das hier so geht.

    Den IDE Sketch habe ich jetzt so verändert, dass ich nach jeder Ausgabe ein delay(25) einfüge.

    Zumindest die doppelten Wertepaare pro Zeile scheint es zu beheben.

    Die Baudrate habe ich auf 115200 geändert. Brachte keine weitere Änderung.

    Manchmal fehlen in der Datei auch einzelne Zahlen. Diese Wertepaar dann rauszuschmeißen ist mit Python auch kein Thema.


    EDIT: Kann das durch die Nutzung von Jumper Kabeln passieren? Würde am Ende alles löten.

    EDIT2: im Seriellen Monitor über IDE alles wie es soll. Hatte ich schon erwähnt? Weiß ich gerade nicht. Da sieht es wunderbar aus.

  • Edit2 schließt eigentlich Edit1 aus. Sonst hätte ich die auch noch in Verdacht gehabt. Probier doch nochmal, die serielle Konsole über raspi-config zu deaktivieren. (evt. mit zwischenzeitlichem Aktivieren). Auch mit dauerhafter Prozessorlast über 70% zappelt da nichts.

  • Nach einer gewissen Zeit schummeln sich dann jedoch wieder ungewollte Zeilenumbrüche ein nach jedem x,y,z Wertepaar

    Nur mal so aus'm Bauch: gib' die Daten mal in HEX aus ... evtl. steht da 0 drin.

    Dann wird nichts ausgegeben, nur der Zeilenumbruch.

    Vielleicht, um ganz sicher zu gehen, im Testmodus eine statische Variable mit einer laufenden Nummer zusätzlich z.B. in Klammern pro Zeile.

    cu,

    -ds-

  • Vielleicht, um ganz sicher zu gehen, im Testmodus eine statische Variable mit einer laufenden Nummer zusätzlich z.B. in Klammern pro Zeile.

    Wie genau meinst du das mit der Variablen? Über minicom für jede Zeile einen Wert einführen? Falls ja - wie? Nichts dazu gefunden.

    Im Anhang die Ausgabe in hex. Hier werden die Umbrüche rausgeschmissen. Wenn ich nun wieder normal ausgebe alles beim Alten...:/


    Edit2 schließt eigentlich Edit1 aus. Sonst hätte ich die auch noch in Verdacht gehabt. Probier doch nochmal, die serielle Konsole über raspi-config zu deaktivieren. (evt. mit zwischenzeitlichem Aktivieren). Auch mit dauerhafter Prozessorlast über 70% zappelt da nichts.

    Ja die Verdrahtung zwischen Sensor und Arduino steht und passt. Das ist klar. Ich dachte eher an die Verkabelung zum RPi. Theoretisch ja nur ein Kabel von Arduino TX zu RPi RX. Das Habe ich aber mal getauscht und im Breadboard einen Pin weiter gesetzt..nichts passiert.

    Serielle Konsole habe ich vorher schon über raspi-config deaktiviert. Schon mehrmals aktiviert und deaktiviert.

    Ich werde jetzt erstmal los einen kleine Halterung bauen für Raspi, Sensorik und einen Lüfter. Nachher gehts weiter. Zur NOT schreibe ich nachher einen Code in Python, betreibe den Arduino am PC und ziehe die Daten via USB in eine .txt um diese manuell hinzuzufügen bei der Auswertung.

    Das frisst gerade ziemlich viel Zeit :no_sad:

Jetzt mitmachen!

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