Eine vielleicht seltsame Frage zur seriellen Schnittstelle

Harry
Moderator
Avatar
Geschlecht:
Herkunft: zwischen Augsburg und Ulm
Alter: 60
Beiträge: 2155
Dabei seit: 03 / 2003
Betreff:

Eine vielleicht seltsame Frage zur seriellen Schnittstelle

 · 
Gepostet: 10.05.2020 - 10:33 Uhr  ·  #1
Hallo Zusammen,

wie der Titel schon sagt, habe ich eine Frage oder eher ein Gedankenspiel zur seriellen Schnittstelle.
Ich kann meine GPS-Empfänger auf 9600, 19200, 38400, .... Baud einstellen. Die Datenmenge, die der uC empfängt, ist immer gleich. Wenn ich nur 2 Datensätze (GPRMC und GPGGA) auswerte, bin ich bei ca. 170 Byte. Bei mehr Datensätzen können es auch 500-600 Byte gesamt werden.
Meine Gedanken dazu: Je schneller ich die Baudrate einstelle, desdo schneller stehen sie dem uC zur Verarbeitung zur Verfügung, also müßte ich mehr Zeit für was anderes übrig haben. Die Frage ist aber, kann der uC die Daten überhaupt schneller verarbeiten, wenn sie schneller im RxD-Puffer stehen oder ist dessen Geschwindigkeit zu langsam, so daß das keine Rolle spielt? Also wer wartet auf wen? Der uC auf die Daten im Puffer oder läuft der Puffer bei höheren Baudraten über, weil der uC die Daten nicht schnell genug raus bekommt? Was ist also besser: Niedrige oder hohen Datenrate?

Gruss
Harry

PS: Wer meinen Gedanken nicht folgen kann, einfach diesen Thread ignorieren :D
Merlin
Administrator
Avatar
Geschlecht:
Alter: 25
Beiträge: 1474
Dabei seit: 03 / 2005
Betreff:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

 · 
Gepostet: 10.05.2020 - 12:13 Uhr  ·  #2
The actual receiving of the data is done by a separate parallel process, and so receiving a single character does not really take any clock cycles (apart from transferring to the internal buffer on an interrupt), and so from that perspective baud does not affect anything. Assuming that the transmitter only transmits records at the same rate (by that I mean records per second, not baud rate) then that also does not affect anything in terms of clock cycles.

However whatever is received must be processed. Don't forget the buffer is only max 255 bytes so you have to process the internal buffer fast enough to avoid overflow. Baud rate does not affect this consideration.

Sorry, no German - I use Google Translate, so sorry if I have missed your point.
rage
Benutzer
Avatar
Geschlecht: keine Angabe
Alter: 65
Homepage: processanalytik.de
Beiträge: 237
Dabei seit: 02 / 2007
Betreff:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

 · 
Gepostet: 11.05.2020 - 12:43 Uhr  ·  #3
Guten Morgen Harry,
so ein Frage am Montagmorgen. Nenene. Aber Spaß bei Seite. Auf unseren aktuellen Loggern, werden von 4 seriellen Schnittstellen Daten eingelesen, hier liegt zwar die Datenrate fest, so das sich nie die Frage stellte ob schneller besser wäre. Die erste Version der Software fragte die Schnittstellen reiherum ab, beim Start grüne LED an und wenn alle Daten da waren grüne LED aus. Hier war ganz schnell zu sehen, viel Zeit bleibt nicht und vor allem wenn noch andere Sachen dazu kommen, Display, Datenaustausch mit anderen Platinen, da bleibt nix. Die zweite Version benutzte 4 Hintergrund-Prozesse und plötzlich war die LED nicht mehr als ca 30 Prozent der Zeit an, wobei halt dann noch dazu kommt, auch in der Zeit wenn also auf Daten gewartet wird kann man noch prima alle anderen Sachen bekaspern. Daher wäre meine Idee eher Hintergrundprozess oder nicht.
cu Ralf
Harry
Moderator
Avatar
Geschlecht:
Herkunft: zwischen Augsburg und Ulm
Alter: 60
Beiträge: 2155
Dabei seit: 03 / 2003
Betreff:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

 · 
Gepostet: 11.05.2020 - 16:17 Uhr  ·  #4
Hallo Ralf,

die Daten werden sowieso in einem Process gelesen :). Man könnte, wenn meine Überlegung stimmt, jetzt annehmen, daß bei 9600 Baud und 170 Byte es ca. 177ms dauert, bis die Daten empfangen sind. Der Process hat Standard-Priorität 5, bekommt also 5xSysTick 10ms=50ms. Am Processanfang wird auf Daten gewartet, solange keine da sind springt er raus. Diese Daten kommen, wenn sie kommen garantiert am Stück ohne weitere Verzögerung. Bei 19200 Baud wäre ich bei ca. 89ms. Überlegung: Wenn der Process Daten bemerkt, die aber noch nicht vollständig da sind, fängt er an zu verarbeiten und vielleicht ist der Empfang fertig, bis der Process soweit ist? Ok 38400 Baud, 44ms Übertragungszeit und dem Process mehr Zeit (Prio 6-8) verschaffen? Nach 60-80ms wäre alles vorbei und der Rest hat großzügige 900ms Zeit für Display, SD & Co.
Was nun wenn ich auch VTG-Daten verarbeiten will? Da kommen dann bis zu 8 Zeilen je 80 Zeichen rein. Auf einmal!
Halt mal, wie wäre es den Process zu locken und wenn alle Daten drin sind den Rest erst zu machen? Dabei den Process sperren. Ich seh das schon richtig, daß bei einem Lock(self) im Process dieser nicht mehr verlassen wird?

Gruss
Harry
Gunter
Administrator
Avatar
Geschlecht:
Herkunft: Frankfurt Main / Germany
Beiträge: 1697
Dabei seit: 02 / 2003
Betreff:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

 · 
Gepostet: 11.05.2020 - 17:38 Uhr  ·  #5
Hallo Harry,

durch ein Lock bekommt der Prozess in der Run Queue den Status "locked".
Der Scheduler wird weiterhin zyklisch aufgerufen, ruft aber keinen anderen
Prozess mehr auf.
Interrupts und Tasks werden aber weiter abgearbeitet.
SchedulerOff; verhindert auch Tasks.
DisableInts; schaltet alles, ausser dem Prozess, aus.

Gruß, Gunter
Gewählte Zitate für Mehrfachzitierung:   0

Registrierte in diesem Topic

Aktuell kein registrierter in diesem Bereich

Die Statistik zeigt, wer in den letzten 5 Minuten online war. Erneuerung alle 90 Sekunden.
MySQL Queries: 15 · Cache Hits: 14   93   107 · Page-Gen-Time: 0.028453s · Speichernutzung: 2 MB · GZIP: ein · Viewport: SMXL-HiDPI