Optimieren von UART-Komunikation, bitte um Meinungen

[JoeM1978]

Als erstes danke ich euch mal für eure Mühe...
und natürlich auch für den vorgelegten Code.

das...

Datenblock(1) = String(datenblock_laenge , 22) 'Wozu?

War dazu gedacht, das ich auch kurze Messages senden kann und der rest mit "lückenfüller" neutralisiert wird.

Hab den Code von dir versucht... bis auf die Ausgabe auf lcd ist das anscheinend funktionierend.
Wobei das LCD eh nur für Testzwecke dranhängt bis die Komunikation fehlerlos steht.
Das LCD ist aber schnell angepasst.

Was mir gedanken macht daran... sollte aus irgendeinem Grund 2 oder mehr Datenblöcke kurz nacheinander gesendet werden
und das hauptprogramm hatte noch keine zeit den Buffer auszulesen...
Wird dann alles, was zuviel gesendet wird einfach verworfen ?

Dann sollte ich mir sozusagen ein "manuelles handshake" einbauen... das die pc-software weiss,
wann der client wieder empfangsbereit ist.

Das war der ursprüngliche grund, weshalb ich den Buffer "so schnell wie möglich" auslesen wollte mit der ISR.

[peterfido]

Was mir gedanken macht daran... sollte aus irgendeinem Grund 2 oder mehr Datenblöcke kurz nacheinander gesendet werden
und das hauptprogramm hatte noch keine zeit den Buffer auszulesen...
Wird dann alles, was zuviel gesendet wird einfach verworfen ?

Bei 9600 Baud und 8 MHz langweilt der sich zwischendurch. Da geht normal nichts verloren. Wenn du aus der Hauptschleife Subs aufrufst, welche lange Pausen beinhalten, oder die Pausen gar in die Hauptschleife legst, dann besteht die Gefahr, dass der Buffer überläuft. Ich teste die Geschwindigleit meiner Programme gern mit einem blinkenden Herz auf dem LCD. Alle 1000 Durchläufe wird das Herz dargestellt oder ausgeblendet. Selbst meine umfangreichen Projekte kommen da gefühlt auf 1000 Durchläufe die Sekunde. Handshaking nutze ich selbstgemacht. Wenn der Raspberry was zum AVR schickt, dann wird eine Antwort passend zum gesendeten erwartet. Kommt diese, aus welchen Gründen auch immer, nicht, dann wird das zuletzt gesendete wiederholt. Da beißt sich auch nichts. Mein Protokoll berücksichtigt auch bereits gestartete Übertragungen, z.B. wenn die Fernbedienung oder eine Taste am Gerät "was zu melden hat".

Ich sende dafür nicht aus jeder Sub direkt per print, sondern schreibe die Daten in einen Sendepuffer. Jeder Durchgang der Hauptschleife ruft eine Sub auf, welche prüft, ob es was zu senden gibt und sendet dann chronologisch nach FIFO art. Der Raspberry macht es ähnlich. Da nutze ich zum Senden ein eigenes C-Programm, welches prüft, ob es evtl. schon in einer anderen Instanz läuft und falls ja, wird eine Pause eingelegt. Meine Tests mit 100 "gleichzeitigen" Aufrufen liefen fehlerfrei. Soviel kommen in der Realität aber gar nicht vor.

[JoeM1978]

Bei 9600 Baud und 8 MHz langweilt der sich zwischendurch

... und genau das hatte ich anfangs komplett falsch eingeschätzt.
ich war erst der meinung, "die paar" Zeichen liegen schon im Buff, bis die erste schleife der isr durch ist. *blöderweise
Ist aber ne bekannte schwäche bei mir. *lach

Wenn man dann das Geschwindigkeitsproblem betrachtet ist auch ganz klar das Bytematch
(wie MagicWSmoke sagte) genau in eine andere Richtung "korrekt" verwendet werden muss.

Der Ansatz, es über Bytematch zu lösen ist an sich nicht schlecht... aber ich muss erst den Buffer füllen lassen...
und danach erst das Auslesen beginnen.

Ich finds aber immerwieder schön was zu lernen. Am besten passiert das natürlich aus eigenen Fehlern

Wo ich gerade bei Bytematch bin...
Was ist der Sinn dahinter, das man Register per Pushall behandeln muss bei Verwendung von Bytematch ?
Ich konnte das aus der Bascom-hilfe nicht wirklich erkennen.
Auch konnte ich nicht finden, welche register denn wirklich dafür verwendet werden.

Wäre schön, wenn da jemand knappe Infos oder nen Link hätte damit ich das nachlesen kann.

[MagicWSmoke]

Was ist der Sinn dahinter, das man Register per Pushall behandeln muss bei Verwendung von Bytematch ?

Die Serialcharmatch ist nichts anderes als die Verlängerung des URXC-Interrupts. Zuerst schreibt Bascom das angekommene Byte in den Puffer, danach wird Serialcharmatch ausgeführt. Bascom sichert für den URXC seine im Interrupt verwendeten Register, aber nicht solche aus Usercode. Wird ASM benutzt, dann ist's sehr einfach, die Register sind dann bekannt, bei Basic-Code eher weniger, dann müsste man alle verwendeten Register in Erfahrung bringen und diese sichern, das Erkennen ist eher schwierig. Deshalb der Rat zu Pushall/Popall.

[JoeM1978]

OK. das ist also...

Empfang (urxc) -> Buffer -> auf Byte/Char-match kontrollieren durch den MC (interne ISR) -> erst bei Treffer in die "User"-ISR springen

... aber ist mir noch nicht ganz verständlich aus welchem Grund die Register dazu gesichert werden müssen.
Würde es sonst zu Überschneidungen kommen beim Empfangsbuffer während intern die routine abläuft ?

[MagicWSmoke]

Weil jeder Interrupt, auch der URXC, mitten im normalen Code unterbrechen kann, müssen alle von einer Interruptroutine veränderten Register gesichert werden, sonst gibt's Verhau.
Der Code für den gepufferten Empfang macht das für die von ihm veränderten Register. Sobald aber User-Code in diese URXC mit "eingehängt" wird, können weitere Register verändert werden.

[JoeM1978]

@MagicWSmoke
Hab mir gerade deinen code genauer angeschaut ... das "rcvd_char = UDR" muss ich glaub ersetzen durch "rcvd_char = inkey()"
und
"Incr db_index" ... soweit ich mich erinner gibts kein "Incr (Var)" in Bascom. Da fall ich selber immerwieder drauf rein.

OK muss mich selber berichtigen... Incr (Var) ... gibt es doch... es war i++ was nicht geht.