Wie man UART abfragt, während man viele andere Dinge verarbeitet

Ich habe ein GPS-Gerät, von dem ich Daten abrufen muss (die NMEA-Strings). Meine MCU ist jedoch viele Male pro Sekunde damit beschäftigt, etwas anderes zu verarbeiten. Gibt es eine Möglichkeit, ein UART/RS232-TTL-Signal zu "pausieren" oder zu puffern, während meine MCU Sachen macht? Ich schaue mir entweder einen dsPIC33FJ128GP802 oder einen AT32UC38x an.

Die Verarbeitung meines OSD kann nicht unterbrochen werden, Interrupts sind also aus.

Benötigen Sie GPS-Daten, während Ihre CPU mit der OSD-Verarbeitung beschäftigt ist? Gibt es eine Möglichkeit, die OSD-Verarbeitung Interrupt-gesteuerter zu machen?
Die OSD-Verarbeitung ist unterbrechungsgesteuert. Bei jeder Komparatoränderung bestimmt er die aktuelle Zeile des Videos und gibt die Folge von Pixeln aus, die in das Video eingebettet werden sollen. Es ist jedoch diese kritische Zeit während der Ausgangsphase, in der der Prozessor beschäftigt ist.
Ich habe meine Antwort bearbeitet, Thomas, hat das überhaupt geholfen?

Antworten (8)

Zwei Dinge.

  1. Machen Sie es so, dass Sie einen Puffer haben und die Interrupts die Daten einfach in die Warteschlange stellen, bis Sie Zeit haben. Machen Sie es so, dass das Parsen des GPS-Strings interruptgesteuert ist.
  2. Ich habe 5 verschiedenen Leuten dabei geholfen. Dies ist besonders einfach, wenn Sie nur einen kleinen Teil der Zeichenfolge benötigen, z. B. Position.

Ich kann auf beide Methoden näher eingehen, wenn mehr Klarheit erforderlich ist.

Randnotiz für Mikrochip. Ich denke, ihr Assistent für den c18-Compiler (habe den c30 noch nicht oft verwendet) wird Ihnen eine Bibliothek geben, mit der Sie die Daten von UART für Sie in die Warteschlange stellen können.

Sie haben andere Interrupts, die niemals verzögert werden können?

Wenn Ihr Bildschirm-Controller mit Interrupts fertig ist, können Sie ihn dann nicht einfach in einen Interrupt auf höherer Ebene stecken?

Dies bedeutet, dass der RX-Daten-Interrupt immer dann Zeit hat, die Daten in eine Warteschlange zu stellen, wenn Sie Ihren Interrupt verlassen. Dies bedeutet auch, dass jedes Mal, wenn Ihre anderen Interrupts ausgelöst werden, sie die von Ihnen erwartete Priorität erhalten.

Platzieren Sie dann in Ihrem Hauptregelkreis, der nicht unterbrechungsgesteuert ist, die Verarbeitung Ihrer GPS-Daten. Das hält die Dinge schön unterteilt. Denken Sie daran, dass Sie bei den meisten GPS-Baudraten lange Zeit haben, Zeichen aus der Zeichenfolge zu ziehen, da 4800 oder 9600 Baud langsam sind ...

Das Problem ist, dass ich die OSD-Verarbeitung nicht unterbrechen kann, oder das Video bricht zusammen und sieht schrecklich aus. Während der OSD-Verarbeitung (ca. 80-90 % der Prozessorzeit) ist der Chip also ziemlich unterbrechungsfrei.
Ahh. Es tut mir leid, ich wusste nicht, wie intensiv Ihre Unterbrechungsanforderung war. Ich überlasse die Antwort Leuten mit einem weniger kritischen Prozess. Ich schreibe bald noch einen.
Ich habe ein bisschen mehr Informationen zu deinem Bild hinzugefügt.
Danke. Mein GPS-Gerät benötigt mindestens 9600 Baud, aber ich kann mich vielleicht einschleichen, indem ich die Bits am Anfang jeder Zeile einlese; Ich bin mir aber immer noch unsicher.
Sie sagten, Sie implementieren bereits ein zweites Bild, was meine zweite Option gewesen wäre, aber andere sind mir zuvorgekommen. Auf diese Weise können Sie den UART zu einem FIFO gehen lassen, wenn Ihr anderer Interrupt nicht bedient wird, ohne die Art und Weise zu ändern, wie die Video-Interrupts behandelt werden.

Ich glaube, dass einige der dsPIC-Familie DMA-Unterstützung in der MSSP-Peripherie haben, die das Puffern des Eingabestroms ohne CPU-Eingriff bis zu einem Punkt ermöglicht, der durch den verfügbaren Speicher begrenzt ist.

Verwenden Sie einen Interrupt, um die GPS-Daten in Blöcken zu verarbeiten. Stellen Sie einfach sicher, dass der Interrupt für Ihre Videoverarbeitungsarbeit auf eine höhere Priorität eingestellt ist, damit er den GPS-Handling-Interrupt stoßen kann.

Es hört sich so an, als müssten Sie Ihren PIC wirklich dem Display widmen, 80-90% CPU-Auslastung ist viel. Ich sehe einige Ähnlichkeiten zwischen einem Computer und seiner Grafikkarte. Ich denke, Sie sollten unbedingt in Betracht ziehen, Ihr Projekt in 2 PICs aufzuteilen, von denen 1 das gesamte Video (wie eine Grafikkarte) und das andere die andere Verarbeitung übernimmt. Dieser zweite PIC kann eine gewisse Flusssteuerung zwischen Ihrem Video-PIC haben, so dass der Video-PIC Sie wissen lässt, wenn er etwas freie CPU-Zeit hat. Sobald Ihr 2. PIC sieht, dass es zusätzliche Zeit gibt, wird er Daten darauf ausgeben.

Zusatz: Das GPS-Paket enthält wahrscheinlich viel mehr Informationen als das, was Ihr Display benötigt, Ihr separater PIC kann die Daten "bereinigen", um Ihnen genau das zu geben, was Sie wollen / brauchen.

Wenn Ihr zweiter PIC nicht viel leistet, können Sie wahrscheinlich mit einem sehr günstigen PIC (unter 3 $) davonkommen. Diese Kosten sind wahrscheinlich die Zeit wert, die Sie beim Codieren und Debuggen auf einem einzelnen PIC sparen.

Das mache ich derzeit mit einem dsPIC33F und einem PIC24F. I2C kann angehalten werden, so dass Daten zwischen den beiden Geräten gesendet werden.
Haben Sie Probleme mit dieser Methode?
Nun, es ist teurer und es ist größer. Wenn ich es vermeiden kann, ist es besser.
Du scheinst eine Frage gestellt zu haben, auf die du nichts anderes als Magie als Antwort akzeptieren willst. Sie sagen, dass Interrupts keine Option sind und das Hinzufügen zusätzlicher Kosten oder ICs keine Option ist. Außerdem sollten Sie in Ihre Frage aufgenommen haben, dass Sie diese Methode bereits anwenden. Wenn Sie weiterhin auf diese Weise Fragen stellen, wird die Community davon ausgehen, dass Sie Fragen stellen, nur um mehr Reputation zu erlangen, und Sie als Spam behandeln. Ich glaube nicht, dass das für irgendjemanden gut sein wird.

Ein weiterer möglicher Grund für den Propeller-Chip, der in dem anderen Thread besprochen wurde, ist das eingebaute Timing für das Video, und Sie können ein separates Zahnrad für RS232 verwenden, ohne das Video zu beeinträchtigen.

Es scheint, dass der AT32UC3B1256 auch eine periphere DMA-Fähigkeit hat, sodass Sie Daten vom GPS empfangen können, ohne Interrupts zu verwenden.

Ich habe eine Videoüberlagerung in einer Anwendung durchgeführt, die eine Abfrage während der Datenanzeige erforderte. Wenn Sie einen Ersatz-FSR zur Verfügung haben, fügen Sie Folgendes ein:

  btfsc INTCONx,RCIF ; Ich habe vergessen, in welchem ​​INTCON es ist
   movff RCREG,POSTINC2 ; Oder welcher FSR frei ist

mindestens einmal alle 16 Zeilen (es kann am bequemsten sein, dies in jeder Zeile zu tun). Nur drei Zyklen pro Linie. Wenn Sie keinen Ersatz-FSR zur Verfügung haben, Ihr Anzeigecode jedoch erweitert und nicht in einer Schleife ausgeführt wird, müssen Sie mindestens alle sechzehn Zeilen Folgendes verwenden:

  movff INTCONx,SerStatus+N ; N=0 für den ersten, 1 für den nächsten usw.
... und dann (nicht unbedingt sofort)
  btfsc SerStatus+N
   movff RCREG,SerData+N

zu einem Preis von drei Zyklen auf einer Linie und zwei auf einer anderen; am Ende der Anzeige:

  lfsr 0, SerData
  btfsc SerStatus+0
   movff SerData+0,POSTINC0
  btfsc SerStatus+1
   movff SerData+1,POSTINC0
  btfsc SerStatus+2
   movff SerData+2,POSTINC0
  ...
  movlw (SerData & 255)
  subwf FSR0L,m
  ; W enthält nun die Anzahl der empfangenen Bytes
  ; Daten befinden sich in SerData+0 bis SerData+(W-1)

Der Trick besteht darin, sich keine Gedanken darüber zu machen, was mit den Daten zu tun ist, während die Anzeige angezeigt wird. Werfen Sie es einfach irgendwohin und sortieren Sie es später aus.

Angenommen, Ihr GPS-Gerät gibt NMEA-Strings mit 4800 bps aus - Sie sollten in der Lage sein, ein paar freie Zyklen in Ihrem Videogenerator zu finden, um einen seriellen Bitstrom zu decodieren.

Fehlt das:

  • Wenn Ihr GPS-Gerät Hardware-Flusskontrolle unterstützt, können Sie es möglicherweise zwischen Frames warten oder wenn Ihr Gerät im Leerlauf ist

  • Eine andere Option wäre eine externe SPI/I2C-zu-UART-Brücke. Einige dieser Geräte haben angemessen große FIFOs, die es ihnen ermöglichen, außerhalb Ihres PIC zu puffern. Warten Sie es erneut während Ihrer Leerlaufzeit

Ich würde mir vorstellen, dass die Kosten einer SPI / I2C-UART-Brücke wahrscheinlich nahe an den Kosten eines zusätzlichen PIC liegen.

4800 Baud ist ein Zeichen alle 2 ms. Dies ist für die meisten Mikrocontroller (einschließlich PICs) ein Hundezeitalter, und Sie sollten KEIN Problem haben, die Daten aus dem Halteregister des UART zu sammeln. Denken Sie daran, dass selbst der einfachste UART einen eingebauten 2-Zeichen-FIFO (das Halteregister und das Schieberegister) hat. Wenn Sie nicht alle 2 ms ein paar Zyklen finden können, um ein Zeichen aufzunehmen, müssen Sie einen kräftigeren Prozessor finden, einen mit einem FIFO, oder den Job aufteilen, wie andere Leute erwähnt haben.

Der von Ihnen erwähnte dsPIC verfügt über 4-Byte-FIFOs auf dem UART und ist auch DMA-fähig. Während 90 % eine hohe Systemlast für das OSD darstellen (sind Sie sicher, dass Sie Ihr OSD so effizient wie möglich ausführen?), weiß ich nicht, warum Sie bei dieser Systemlast Probleme haben sollten, einen 4800-Byte-NMEA-Stream einzuziehen . Das Verpassen des einen oder anderen GPS-Updates wird Ihre Anwendung wahrscheinlich auch nicht allzu sehr beeinträchtigen.

Die meisten seriellen Geräte implementieren eine Art 'Flusskontrolle' == dies ist entweder über zusätzliche Drähte (RTS 'Request to Send', CTS 'Clear to Send') ein 'Handshake', der es dem empfangenden Gerät ermöglicht, CTS hi oder lo auf Suspend zu setzen Übertragung ..

.. ODER (für Geräte, die nur RxD/TxD-Leitungen verwenden) 'Software-Flusskontrolle' ( == Sie senden ihnen einen bestimmten ASCII-Code, um zu sagen: 'Senden stoppen' und einen anderen, um 'OK, jetzt neu starten' zu sagen)

Schlagen Sie in Ihrem GPS-Datenblatt nach 'Flusskontrolle'.

Wie man UART abfragt, während man viele andere Dinge verarbeitet
AntwortenHierDatenschutz-Bestimmungen1y, 0v