Eine vielleicht seltsame Frage zur seriellen Schnittstelle

Harry

Moderator

Gender:
Location: zwischen Augsburg und Ulm
Age: 59
Posts: 2134
Registered: 03 / 2003

Subject:

Eine vielleicht seltsame Frage zur seriellen Schnittstelle

· Posted: 10.05.2020 - 10:33 · #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

Merlin

Administrator

Gender:
Age: 24
Posts: 1409
Registered: 03 / 2005

Subject:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

· Posted: 10.05.2020 - 12:13 · #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

Gender: n/a
Age: 65
Homepage: processanalytik.de
Posts: 237
Registered: 02 / 2007

Subject:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

· Posted: 11.05.2020 - 12:43 · #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

Gender:
Location: zwischen Augsburg und Ulm
Age: 59
Posts: 2134
Registered: 03 / 2003

Subject:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

· Posted: 11.05.2020 - 16:17 · #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

Gender:
Location: Frankfurt Main / Germany
Posts: 1697
Registered: 02 / 2003

Subject:

Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle

· Posted: 11.05.2020 - 17:38 · #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

Eine vielleicht seltsame Frage zur seriellen Schnittstelle

Registered users in this topic