Nextion Datenübertragung seriell

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Nextion Datenübertragung seriell

      Hallo zusammen,

      hier noch eine Frage an Anwender, die das Nextion Display schon mal genutzt haben.Meine Applikation läuft soweit.
      Jetzt stand natürlich die Erweiterung an.
      Also habe ich eine weitere Seite im Nextion hinzu gefügt. Damit habe ich jetzt Probleme.
      Sobald ich die 3 Seite ( Page 2 ) aufrufe, wird über die serierlle Schnittstelle an den Mega 2560 was vom Nextion geschickt.

      Dieses passiert bei den Seiten 1 8 Page 0 ) und 2 ( Page 1) nicht.

      Das Nextion überträgt immer 26, 255,255,255

      Teste ich die Applikation im Debug Mode der Nextion Software, sehe ich im Debugfenster nichts.


      Woran kann das liegen?




      Gruß
      Thomas
    • Ich habe nur einen Button auf der Page 2 ( Seite 3) . Dieser ist nur zum Rücksprung auf die vorhergehende Seite.

      Habe auch die Page 1 auf Page 2 (Seite 3) kopiert und nur den Back Button geändert. Auch hier kommt die Übertragung 26,255,255,255.

      Wie schon geschrieben funktioniert es im Debugger ohne Probleme.

      Gruss Thomas
    • Danke für den Tip

      Wenn das Programm meint es sei auf Seite 0 (ist aber tatsächlich auf 1/2/3) werden die Fehlermeldungen unausweichlich sein.

      Ich habe immer wieder in eine Variable was geschrieben. Diese Variable aber auf der Seite 3 nicht benutzt.
      Dadurch kam der Fehler zustande.

      Hier noch eine Frage:

      Das Nextion überträgt immer zum Schluss 3 X FF

      Leider bei meinem Programm nicht. Ich bekomme nur 1 Mal das FF.

      Habe im Programm Zeile 301 die Abfrage auf 1 gesetzt und damit funktioniert es.

      Wo habe ich hier meinen Fehler?

      Habe beide Projekte mit angehängt.

      In der Zipdatei ist das HMI Projekt. Musste leider einige Bilder herausnehmen, damit die Größe hier passt.

      Gruß Thomas
      Files
    • An deinem Programm kann ich 3 Fehler entdecken:
      1. Deine Abfrage im Block "If New_Data = 1 then" ist fehlerhaft. Siehe Zeile 147
        Hier die Zeile:
        if Datin(1) = &H50 and Datin(2) = &H20 and Datin(3) = &H30then
        Hinten muss ein Space rein zwischen der Hex-Ziffer und den then.
        Wundert michDas dürfte aber nicht dein Problem sein.
      2. Zu Beginn in der Hauptschleife schreibst du in Zeile 111 folgendes:
        Bc = 0
        Das beist sich mit der Empfangs-ISR (Rec_isr:). Denn dort verwendest du diese Variable, um die empfangenen Bytes hochzuzählen. Es macht also keinen Sinn, den Zähler in der Hauptschleife ständig auf 0 zu setzen. Das stört nur den Empfang bzw die Ablageposition des empfangenen Bytes im Array.
        Das dürfte diverse Instabilitäten und merkwürdige Effekte auslösen. Vielleicht ist dir schon irgendwie was aufgefellen? Z.B Button reagiert nicht immer oder ähnliches?
      3. Ich vermute aber, dass dein Problem in der Rec_isr: selbst liegt.
        Bekannterweise sollte man Print in ISR-Routinen generell meiden.
        In deinem Fall führt es dazu, dass die ISR über 7000 Takte zur Abarbeitung benötigt. Das sind ich glaube lt. Simulator 437µs gewesen.
        Deine Baudrate ist 57600. Bedeutet, dass 5760 Bytes je Sekunde übertragen werden (1 Startbit, 8 Datenbit, 1 Stoppbit = 10 Bit je übertragenes Byte).
        Ein Byte benötigt daher 173µs für die Übertragung. Die ISR braucht also rund 2,5 mal länger als ein Byte für die Übertzragung. Die Folge ist, dass Daten verschluckt werden.
        Ohne den Print-Anweisungen in der ISR, werden nur um die 170 Takte benötigt.
      Probiers mal aus. Rückmeldung wäre interessant.
    • Hallo Mitch64

      recht herzlichen Dank für Deine Tips.

      Habe alles raus genommen und jetzt funktioniert alles super.

      Auch mit dem 3 x FF. :thumbup:
      Da haben meine Print Anweisungen doch einiges verschluckt.

      Ich habe noch eine Frage.

      Im Programm nutze ich den Int0 für die Drehzahlerfassung und im Unterprogramm Impuls werte ich den Timer aus.

      Das gleiche muss ich nun auch noch für die Geschwindigkeit machen. Hierzu wollte ich den Int1 nehmen.

      Nun meine Frage.

      Gibt es hier Probleme wenn der Int1 zur gleichen Zeit kommt wie der Int0?

      Es kann ja im schlimmsten Fall dazu kommen.

      Kann man Prioritäten für die enzelnen Interrupts vergeben.

      Eine Idee von mir war, das ich die Geschwindigkeitsmessung auf einem separaten Uno Nano mache und alle 500ms die Geschwindigkeit per Seriell
      dann zum 2560 schicke.

      Gruß
      Thomas
    • towaes wrote:

      Kann man Prioritäten für die enzelnen Interrupts vergeben.
      Nein, zumindest nicht bei den Tiny und Mega's. Möglicherweise geht das mit XMegas, mit denen habe aber noch nie was gemacht.
      Die Reihenfolge der Prioritäten ist festgelegt und entspricht der Reihenfolge der im Datenblatt angegebenen Interrupt-Vektoren.
      Reset hat die höchste. Und INT0 ist höher priorisiert als INT1. Reihenfolge bitte dem Datenblatt entnehmen.


      towaes wrote:

      Gibt es hier Probleme wenn der Int1 zur gleichen Zeit kommt wie der Int0?
      Jain. Es werden dann beide Interrupts nacheinander abgearbeitet in der Reihenfolge der Prioritäten.
      Aber. Wenn du Zeit messen willst und ein Interrupt braucht etwas länger, muss der nachfolgende Interrupt Timerwerte auslesen, die nicht mehr dem Timerwert entsprechen zum Zeitpunkt des Interrupts. Man würde also falsche bzw. verfälschte Zeiten messen. Wie falsch hängt wieder von der Verarbeitungszeit der ISR ab und der Häufigkeit der Interrupts.

      In solchen Fällen ist es klug, die ISR in Assembler zu machen, um die Verarbeitungsdauer möglichst gering zu halten.
      Ein Anderer Weg wäre das ICP-Register zu verwenden. Also eine Frequenz/Drehzahl auf den ICP-Pin zu geben. Das geht aber oft nur mit Timer 1 und meist nur mit einem ICP-Pin. Hier auch das Datenblatt konsultieren.

      Eine Falle gibt es aber noch bei den Interrupts, die es zu bedenken gibt.
      Also angenommen, es kommen INT0 und INT1 Interrupts in schneller Folge an, und die Frequenz von INT0 ist deutlich höher.
      Dann wird beispielsweise INT0 und 1 ausgelöst. Der Controller bedient INT0 (weil Prio höher).
      Dann kommen schon wieder Interrupts auf INT0 und INT1, die ISR INT0 ist aber nicht nicht beendet.
      Dann wird nur das INT0 Flag gesetzt, das INT1 ist ja bereits gesetzt.
      Ist nun die ISR zu Ende, schaut der Controller nach, welcher Interrupt ankam, beginnent mit höchster Prion.
      Das bedeutet, der INT0 wird wieder verarbeitet, obwohl der INT1 schon länger wartet.
      Das kann so weit gehen, dass INT1 nie aufgerufen wird und nur INT0 bearbeitet wird. Das Programm scheint für den Anwender zu "hängen", obwohl der Controller die ganze Zeit INT0 Verarbeitet aber zu nix anderem mehr kommt. So gehen dann an INT1 Interrupts verloren.

      Das ist auch der Grund, warum ISR-Routinen so kurz wie möglich gehalten werden sollen.
      Und das ist eigentlich auch die Begründung, warum bei dir nur 1xFF durch kam, obwohl das Display 3xFF gesendet hat.
    • Noch einen Nachtrag.
      Wenn du die Anzahl Flanken pro Sekunde an den Interrupt-Eingängen kennst, kannst du schön im Simulator überprüfen, ob die ISR-Verarbeitung schnell genug ist. Für solche Dinge ist der Simulator echt Gold wert!

      Da die Prios der Interrupt fix sind, könnte es für dich eine Überlegung sein, welcher der Messwerte für dich der genauere sein sollte. Und diesen dann auf INT0 legen oder besser auf ICP-Pin.