Optimieren von UART-Komunikation, bitte um Meinungen

[MagicWSmoke]

ok... also ist das sozusagen wie der gepufferte Empfang... nur eben "manuell".

Ich würd' eher sagen eine andere Version des gepufferten Empfangs.

bei 9600baud, meinst da könnte es passieren, das während dieser "manuellen Bufferroutine" ein zweites Zeichen schon ankommt ?

Keine Chance

9600 Baud sind 9600 Bits pro Sekunde, ein Zeichen sind mit Start- und Stopbit rund 10 Bits, also sind's rund 960 Zeichen pro Sekunde, das sind etwas mehr als 1 mS für ein Zeichen.
In dieser Zeit hat der µC ca. 8000 Takte zur Verfügung, meine gepufferte Routine braucht so ca. 140-200 Takte pro Aufruf.

Bei 400000 Baud würdest Du an Grenzen stoßen.

Würde das in einer "warteschleife hängen oder einfach verworfen werden ?

Ohne Handshake gehen Zeichen verloren, wenn der UART-Puffer voll ist und nichts mehr aufnehmen kann.

[JoeM1978]

joa... und da die routine eh sofort bei jedem zeichen aufgeht sollte das kein problem sein.

Jetzt muss ich nur aufpassen, das ich bei anderen ISR keine gravierenden Verzögerungen reinbekomm.
Denn dann könnte es doch seltsame auswirkungen haben, je nachdem welche ISR höherer priorität hat.

Betreffs deinem Code... die Array buff() und data_block() ...
Gibts eine schnellere möglichkeit ein Array zu löschen als eine For_Next-Schleife ?
Denn wenn ich unterschiedlich lange Messages Empfange wäre es schon störend, wenn der Inhalt der vorherigen noch drinn steht.

[MagicWSmoke]

Denn dann könnte es doch seltsame auswirkungen haben, je nachdem welche ISR höherer priorität hat.

Sobald eine ISR aktiv ist, sind alle anderen gesperrt, d.h. eine Endlosschleife in einer anderen ISR kann alles blockieren.
Eine Priorität gibt's nur dann, wenn mehrere Interruptanforderungen anstehen und Interrupts erlaubt sind, dann wird derjenige mit höchster Priorität zuerst ausgeführt.

Gibts eine schnellere möglichkeit ein Array zu löschen als eine For_Next-Schleife ?

Memcopy() mit entsprechender Option ist recht schnell. Aber das ist unnötig, stört doch nicht, wenn da was drinsteht. Du musst nur wissen, wie lange die Nutzdaten tatsächlich sind.
Wenn Du hier die Länge in eine zusätzliche Variable kopierst, weißt Du das immer.

tmp = memcopy(buff(1) , data_block(1) , db_index)
  data_block_len = db_index

[JoeM1978]

Eine Priorität gibt's nur dann, wenn mehrere Interruptanforderungen anstehen und Interrupts erlaubt sind, dann wird derjenige mit höchster Priorität zuerst ausgeführt.

Dann ist also innerhalb der ISR ein "Disable Interupts"... und
ind der letzten Zeile "Enable Interupts" sowieso nutzlos, da das automatisch gesperrt ist.

Die aktuelle Datenblock-Länge zu speichern ist eine Möglichkeit. Stimmt.

In die Gegenrichtung... also Daten senden mach ich am einfachsten über

Print"{irgendwas}";

?
oder wäre es sinnvoll das ebenfalls über das Register zu schicken ?

Ich hab gelesen, das das UDR das Register ist für I/O ... also sprich für beide Richtungen.
Ist das Problematisch, wenn Während dem Senden daten empfangen werden ?
Das gibt doch dann nur durcheinander vermute ich mal.

[MagicWSmoke]

Man kann auch Interrupts in einer ISR extra erlauben, "nested interrupts", aber das ist nicht ungefährlich und hat 'ne Menge Tücken.

Print ist problemlos benutzbar, nur mit allem wie Input usw. würdest Du Probleme haben, weil sich die URXC sofort die Daten greift. Geht aber trotzdem, einfach den Interrupt verbieten.

Nein, ist kein Problem. Schreibt z.B. ein Print auf das UDR, so hat das keinen Einfluss auf daraus gelesene Werte, das wird wie zwei unterschiedliche Register unter einem Namen behandelt.

[JoeM1978]

Fein. gut zu wissen, das es dann doch unterschiedliche Register für RX und TX sind.

Immerhin sollen schon einige Daten zum PC Wandern also Sensoren, odometrie, evtl. Statusmeldungen...
Das wäre käse, wenn das alles warten müsste.

Deshalb möcht ich ja auch lieber vorher die Komunikation genau hinterfragen... nich das es
späther schon probleme gibt, wenn z.b. Radsensoren/Drehgeber paar mal in der Sekunde Werte senden sollen.

Naja... ich frag einfach was ich nicht versteh... irgendwann machts peng und es bleibt im Hirn hängen
(oder bringt mich zur verzweiflung)*lach

[MagicWSmoke]

Deine Anfangslösung mit 2mS Waits hätte solch eine Blockade verursacht, da dort für den Empfang die ISR nicht verlassen worden wäre, hätte also für max 32mS blockiert. Interruptgesteuert dagegen wird nix blockiert, man könnte noch mit gepuffterem Senden bei dieser niedrigen Baudrate Rechenleistung freimachen.