closed

Loginbox

Please enter your username and password into the following fields to log in.


  • Username:
  • Password:
  •  
  • Auto log in on every visit.


  •  

Eine vielleicht seltsame Frage zur seriellen Schnittstelle



Harry offline
PowerUser
Avatar
Gender: male
Location: GERMANY  zwischen Augsburg und Ulm
Age: 55
Posts: 1635
Registered: 03 / 2003
Private message
Subject: Eine vielleicht seltsame Frage zur seriellen Schnittstelle  -  Posted: 10.05.2020 - 10:33   -  
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
Elektronik arbeitet mit Rauch - wenn man den Rauch raus läßt, funktioniert es nicht mehr.
Electronics works with smoke - if you let the smoke out, it works no longer.
This post has been edited 1-times. Last edit: 10.05.2020 - 10:34 by Harry.
go down go up
Merlin offline
Schreiberling
Avatar
Gender: male
Location: UNITED KINGDOM 
Age:
Posts: 885
Registered: 03 / 2005
Private message
Subject: Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle  -  Posted: 10.05.2020 - 12:13   -  
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.
Merlin.

:magic:

Software is a black art.
go down go up
rage offline
Benutzer
Avatar
Gender: n/a
Location: n/a 
Age: 60
Posts: 183
Registered: 02 / 2007
Homepage Private message
Subject: Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle  -  Posted: 11.05.2020 - 12:43   -  
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
go down go up
Harry offline
PowerUser
Avatar
Gender: male
Location: GERMANY  zwischen Augsburg und Ulm
Age: 55
Posts: 1635
Registered: 03 / 2003
Private message
Subject: Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle  -  Posted: 11.05.2020 - 16:17   -  
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
Elektronik arbeitet mit Rauch - wenn man den Rauch raus läßt, funktioniert es nicht mehr.
Electronics works with smoke - if you let the smoke out, it works no longer.
This post has been edited 1-times. Last edit: 11.05.2020 - 16:20 by Harry.
go down go up
Gunter offline
Administrator
Avatar
Gender: male
Location: GERMANY  Frankfurt Main / Germany
Age:
Posts: 1649
Registered: 02 / 2003
Private message
Subject: Re: Eine vielleicht seltsame Frage zur seriellen Schnittstelle  -  Posted: 11.05.2020 - 17:38   -  
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
2 Dinge sind unendlich: das Universum und die menschliche Dummheit.
Aber bei dem Universum bin ich mir noch nicht ganz sicher
--
Albert Einstein

---
The concept of global warming was created by and for the Chinese in order to make U.S. manufacturing non-competitive
--
Donald J. Trump on Twitter
This post has been edited 2-times. Last edit: 11.05.2020 - 17:51 by Gunter.
go down go up
 


Registered users in this topic
Currently no registered users in this section

Delete cookies of this forum  •  FAQ / Help  •  Team page  •  Imprint   |  Local time: 01.06.2020 - 03:07