AVR128DB USART Transmit Buffer

[Peter S. (cbscpe)]

Im Datenblatt vom AVR128DB steht nur etwas von einem Transmit Buffer 
aber nichts davon wie lang der ist. Auf dem ATMega1284P und dem 
ATMega1280 war der nur ein Byte gross und es gibt da leider eine 
Anwendung da spielt das eine Rolle und entsprechend gibt es Probleme als 
ich diese auf den AVR128DB migrierte. Aber so wie es aussieht hat der 
AVR128DB eine Transmit Buffer von 4 Bytes. Weiss jemand mehr darüber?

Peter

[Volker B. (Firma: L-E-A) (vobs)]

Peter S. schrieb:
> Im Datenblatt vom AVR128DB steht nur etwas von einem Transmit Buffer
> aber nichts davon wie lang der ist.

Also ich interpretiere "The transmitter consists of a two-level write 
buffer"... als 2 Bytes.

Beim Empfänger steht "The USART receiver is doublebuffered".
Ich sehe keinen Grund, warum der Puffer des Senders dann größer sein 
sollte.

Aber ich gebe Dir Recht, das Datenblatt ist mal wieder sehr "Microchip 
like" :-/

Grüßle,
Volker

[Peter D. (peda)]

Peter S. schrieb:
> Auf dem ATMega1284P und dem
> ATMega1280 war der nur ein Byte gross

Das reicht doch völlig aus. Man muß doch nur puffern, damit der 
Interrupt schon das nächste Byte aus dem FIFO lesen kann. Die Bytes 
werden dann lückenlos gesendet. Mit einem größeren Puffer geht es auch 
nicht schneller.

[Peter S. (cbscpe)]

Peter D. schrieb:
> Peter S. schrieb:
>> Auf dem ATMega1284P und dem
>> ATMega1280 war der nur ein Byte gross
>
> Das reicht doch völlig aus. Man muß doch nur puffern, damit der
> Interrupt schon das nächste Byte aus dem FIFO lesen kann. Die Bytes
> werden dann lückenlos gesendet. Mit einem größeren Puffer geht es auch
> nicht schneller.

Das war ja auch nicht das Problem, ein Byte reicht. Probleme habe ich 
jetzt auf dem AVR128DB weil es eben mehr ist.

[Peter D. (peda)]

Peter S. schrieb:
> Probleme habe ich
> jetzt auf dem AVR128DB weil es eben mehr ist.

Wo steht das?
Lt. Datenblatt ist das Verhalten gleich den standard AVRs, d.h. man kann 
max 2 Bytes in einem Rutsch schreiben, das 1. landet sofort im SRG, das 
2. im Puffer.

Aber im Unterschied zu den standard AVRs ist der RX-Puffer auch nur 1 
Byte groß. Die standard AVRs hatten ja noch 2 Byte RX-Puffer.
Die standard AVRs konnten also 3 Byte in einem Rutsch lesen (2 * Puffer 
+ SRG). Erst ab dem 4. Startbit kommt es zum Verlust des 3. Bytes.

[Falk B. (falk)]

Peter S. schrieb:
> Das war ja auch nicht das Problem, ein Byte reicht. Probleme habe ich
> jetzt auf dem AVR128DB weil es eben mehr ist.

Sicher? Oder nur eine schlechte Programmierung im Original, welche, 
warum auch immer, jetzt fehlschlägt. Was geht denn nicht?

[Peter S. (cbscpe)]

Es geht darum die Funktion eines alten seriellen Interfaces (DLV11 für 
eine PDP-11) abzubilden. Dieses serielle Interface hatte auch einen 
Transmit Buffer von einem Byte, und einen Transmit Buffer Empty 
Interrupt. Das passte eins zu eins zum USART eines ATMega mit dem DRE 
interrupt und so war es einfach nur ein Übersetzung der IO Adressen und 
der Status bits. Gewisse Treiber auf der PDP-11 Seite haben sich darauf 
verlassen, dass es nur ein Byte war und das funktioniert dann natürlich 
nicht wenn ich den Code auf einen AVR DA oder DB portiere. Die Programme 
auf dem PDP-11 anzupassen geht leider nicht, da nicht von allen Stellen 
im OS der Source Code verfügbar ist. Aber das war auch nicht die Frage, 
ich wollte einfach wissen ob es da eine offizielle Dokumentation gibt, 
die sagt dass der Transmitbuffer mehr als ein Byte hat. Dass ich die 
Emulation für eine AVR DA DB anpassen muss ist mir schon klar.

[Ob S. (Firma: 1984now) (observer)]

Peter D. schrieb:

> Aber im Unterschied zu den standard AVRs ist der RX-Puffer auch nur 1
> Byte groß.

Das DB sagt was anderes (Abschnitt 25.2):

> The transmitter consists of a single-write buffer, a Shift register,
> and control logic for different frame formats. The receiver consists
> of a two-level receive buffer and a Shift register

[Ob S. (Firma: 1984now) (observer)]

Peter S. schrieb:

> ich wollte einfach wissen ob es da eine offizielle Dokumentation gibt,
> die sagt dass der Transmitbuffer mehr als ein Byte hat.

Nein. Aber es gibt ein offizielles Statement im DB, was besagt, dass es 
eben nur ein Byte ist (Abschnitt 25.2):

> The transmitter consists of a single-write buffer, a Shift register,
> and control logic for different frame formats.

Also eigentlich alles genau so wie bei den Classic-Megas (und den 
wenigen Classic-Tinys mit UART).

[Volker B. (Firma: L-E-A) (vobs)]

Ob S. schrieb:

> Nein. Aber es gibt ein offizielles Statement im DB, was besagt, dass es
> eben nur ein Byte ist (Abschnitt 25.2):

Welches Datenblatt nutzt Du denn? Bei den mir vorliegenden Datenblättern 
für AVR128DB28/32/48/64 behandelt Kapitel 25 den TCD Timer. Der Usart 
wird in Kap. 27 behandelt. Und dort steht in Abs. 27.2.:
"The transmitter consists of a two-level write buffer, a Shift register, 
and control logic for different frame formats. The receiver consists of 
a two-level receive buffer and a Shift register."

Grüßle,
Volker

[Ob S. (Firma: 1984now) (observer)]

Volker B. schrieb:

> Welches Datenblatt nutzt Du denn?

Rev. A - 03/2020 (initial release)

[Ob S. (Firma: 1984now) (observer)]

Ob S. schrieb:
> Volker B. schrieb:
>
>> Welches Datenblatt nutzt Du denn?
>
> Rev. A - 03/2020 (initial release)

Hab' mir gerade das aktuelle gezogen und die Revision History 
durchgesehen. Eine diesbezüglich Änderung der UART-Eigenschaften ist 
darin nirgendwo erwähnt.

Typisch MC. Mit deren Datenblättern kann man sich nur noch den Arsch 
abwischen, für mehr taugen die nicht. Ich will Atmel zurück.

[Mario M. (thelonging)]

Das Blockdiagramm im Datenblatt zeigt auch einen zweistufigen Puffer. 
Man könnte in der Senderoutine einfach auf TXC warten, statt auf DRE. 
Außer es stört, dass u.U. Lücken zwischen den Bytes sind.

[Ob S. (Firma: 1984now) (observer)]

Mario M. schrieb:
> Das Blockdiagramm im Datenblatt zeigt auch einen zweistufigen Puffer.
> Man könnte in der Senderoutine einfach auf TXC warten, statt auf DRE.
> Außer es stört, dass u.U. Lücken zwischen den Bytes sind.

Ich habe mir beispielhaft andere DBs der aktuellen AVR8-Generation 
angesehen, die reden ebenfalls alle von einem zweistufigen TX-Buffer. 
Wird also vermutlich korrekt sein.

Wenn ich das nächste Mal so ein Teil am Debugger habe, werde ich 
trotzdem mal ein kleines Testprogramm schreiben, mit dem man das 
zweifelsfrei herausbekommen kann. Ist ja kein großes Ding, sowas zu 
schreiben.

[Falk B. (falk)]

Im Zweifelsfall programmiert man sich ein kleines Testprogramm mit ein 
paar Testpins und mißt mit dem Oszi, was abgeht.

[Peter S. (cbscpe)]

Ja da steht immer nur etwas von einem TX Buffer und ein solcher ist auch 
dargestellt. Aber ich habe mir jetzt ein kleines Testprogram gemacht und 
DREIF wird erst nach dem vierten Character gelöscht und es geht kein 
Zeichen verloren. Der hat definitiv mehr als ein Byte. Ja ich werde wohl 
den TXC Interrupt nehmen müssen und den 1 Byte Buffer für die PDP-11 in 
Software emulieren müssen. Ich kann später mit einem echten DLV-11 
vergleichen, dann sehe ich ob das wirklich viel ausmacht. Die Lücke 
dürfte ja nicht sehr gross werden. Der AVR ist ja recht flott. U.U. ist 
er sogar schneller als die original IC ein CDP6402 oder DC319, die 
brauchen ja auch etwa die Zeitmfür ein halbes bit bis der Buffer 
übertragen ist. Bei 115200baud sind das 5usec. Das schafft der AVR auch.

[S. L. (sldt)]

  ldi    tmp0,'A'
  put    USART1_TXDATAL,tmp0
  ldi    tmp0,'B'
  put    USART1_TXDATAL,tmp0
  ldi    tmp0,'C'
  put    USART1_TXDATAL,tmp0
  ldi    tmp0,'D'

bringt "AB" auf einem AVR128DB28; übrigens genauso wie auf einem 
AVR128DA28, obwohl in dessen aktuellem Datenblatt unter '25.2 Overview' 
steht:
'The transmitter consists of a two-level write buffer, a shift register, 
and control logic for different frame formats.'

[Ob S. (Firma: 1984now) (observer)]

Peter S. schrieb:

> Aber ich habe mir jetzt ein kleines Testprogram gemacht und
> DREIF wird erst nach dem vierten Character gelöscht

D.h.: auch die aktuellen Datenblätter stimmen nicht!

[Ob S. (Firma: 1984now) (observer)]

S. L. schrieb:
>

>   ldi    tmp0,'A'
>   put    USART1_TXDATAL,tmp0
>   ldi    tmp0,'B'
>   put    USART1_TXDATAL,tmp0
>   ldi    tmp0,'C'
>   put    USART1_TXDATAL,tmp0
>   ldi    tmp0,'D'
>

> bringt "AB" auf einem AVR128DB28; übrigens genauso wie auf einem
> AVR128DA28, obwohl in dessen aktuellem Datenblatt unter '25.2 Overview'
> steht:
> 'The transmitter consists of a two-level write buffer, a shift register,
> and control logic for different frame formats.'

Das würde bedeuten: doch nur eine Pufferstufe. Steht aber im Konflikt zu 
dem, was der TO herausbekommen haben will. Und im Konflikt zum aktuellen 
DB sowieso.

[Falk B. (falk)]

Ob S. schrieb:
> Das würde bedeuten: doch nur eine Pufferstufe. Steht aber im Konflikt zu
> dem, was der TO herausbekommen haben will. Und im Konflikt zum aktuellen
> DB sowieso.

Naja, sooo schnell geht es glaube ich auch nicht. Wo steht, daß der 
Puffer mit nahezu CPU-Takt gefüttert werden kann? Man sollte wenigstens 
das DREIF Flag zwischendurch prüfen. Vor allem, weil das realistisch 
ist. Kann sein, daß der Puffer sie wenigen Takte extra braucht, um echt 
puffern zu können.

[S. L. (sldt)]

> Naja,...

Stimmt: zweimal 'rjmp pc+1', also 4 Takte, zwischengeschaltet, erscheint 
"ABC".

[Peter S. (cbscpe)]

Mein Test Program macht wegen Tests und internen Traces etwas mehr und 
vor allem fragt es jedesmal das DREIF ab. Im Bild sieht man die gelben 
Impulse vom PA4, als ausser dem ersten sind das alles Pulse wenn er das 
Zeichen platziert. Man sieht ich kann 4 Characters absetzen und weitere 
erst wenn mindestens eines über die Leitung gerauscht ist. Es ist 
übrigens ein AVR128DB64 (ich brauchen eben mindestens 5 USART)

;
;  2  DREIx Test
;
report2:
  ldi  r17, USART_TXCIF_bm
  sts  USARTA+USART_STATUS_offset, r17
  sbi  b_PA4
report2_010:
  lds  r17, USARTA+USART_STATUS_offset
  sbrs  r17, USART_DREIF_bp
  rjmp  report2_010      ; Wait for all transmissions complete
  cbi  b_PA4
  ldi  r20, 10
  ldi  r21, 'A'
;
;  Start Break
;
  sbi  b_BRKA
;
;  Start sending Characters
;
report2_020:
;
;  First Report the USART_STATUS with Time-Stamp
;
  cli
  sbi  b_PA4
  lds  yl, extptr+0
  lds  yh, extptr+1
  movw  xh:xl, yh:yl
  adiw  xh:xl, 4
  andi  xh, 0xF
  sts  extptr+0, xl
  sts  extptr+1, xh
  subi  yl, low(exttrace)
  sbci  yh, high(-exttrace)
  ldi  r16, SLUTRACE_gm | SLUREAD_bm | SLUXCSR_gm | SLUB_bm
  st  Y+, r16
  lds  r17, USARTA+USART_STATUS_offset
  st  Y+, r17
  lds  r18, TCB2_CNTL
  lds  r19, TCB2_CNTH
  st  Y+, r18
  st  Y+, r19
  cbi  b_PA4
  sei
  sbrc  r17, USART_DREIF_bp
  rjmp  report2_040      ; Send characters until 
  cbi  b_BRKA        ; the TXBUFFER is busy
report2_030:
  lds  r17, USARTA+USART_STATUS_offset
  sbrs  r17, USART_DREIF_bp
  rjmp  report2_030

report2_040:
  sts  USARTA+USART_TXDATAL_offset, r21
  inc  r21
  dec  r20
  brne  report2_020      ; Loop
  ret          ; Finish after max characters

[Ob S. (Firma: 1984now) (observer)]

Falk B. schrieb:

> Kann sein, daß der Puffer sie wenigen Takte extra braucht, um echt
> puffern zu können.

Ja, da ist was dran. Es ist nicht ungewöhnlich, dass solche Puffer 
irgendwie mit der IRQ-Logik gekoppelt sind, das ist im Gegenteil die 
Regel.

[Ob S. (Firma: 1984now) (observer)]

Peter S. schrieb:

> Mein Test Program macht wegen Tests und internen Traces etwas mehr und
> vor allem fragt es jedesmal das DREIF ab. Im Bild sieht man die gelben
> Impulse vom PA4, als ausser dem ersten sind das alles Pulse wenn er das
> Zeichen platziert. Man sieht ich kann 4 Characters absetzen und weitere
> erst wenn mindestens eines über die Leitung gerauscht ist.

Also ich kann das nicht wirklich sehen. Dazu ist das Bild vermutlich zu 
weit verkleinert wurden. Kannst du das bitte noch mal in 
Originalauflösung posten?

[Ob S. (Firma: 1984now) (observer)]

Ob S. schrieb:

> weit verkleinert wurden. Kannst du das bitte noch mal in
> Originalauflösung posten?

Natürlich als *.png, nicht als *.jpg...

[Peter S. (cbscpe)]

Hier jetzt als PNG.

Und wie Falk geschrieben hat, natürlich lief das alles in Interrupts ab, 
schliesslich muss der AVR auch noch andere Dinge erledigen.

Die Fassung mit TXC Interrupt und dem emulierten TXBUFFER nimmt langsam 
Form an.
Grundsätzlich funktioniert jetzt transmit und receive. Der Delay 
zwischen den Zeichen vergrössert sich kaum (wir sprechen da von 
Mikrosekunden). Was jetzt noch harzt ist die Interaktion mit dem 
TXBUFFER und dem PDP-11 Interrupt.

[Ob S. (Firma: 1984now) (observer)]

Peter S. schrieb:

> Hier jetzt als PNG.

Danke, da kann man schon deutlich mehr sehen. Aber leider: Es ist immer 
noch nicht möglich, die relevanten Details genau genug zu sehen, um z.B. 
die Abzählung der Pufferstufen zu ermöglichen. Wobei auch interessant 
wäre, inwiefern sich die Verknispelung des Puffers mit der IRQ-Logik 
auswirkt. Denn das Testprogramm von S.L. hat ja gezeigt, dass die erste 
Stufe des Buffer durchaus etwas anders ist, als die nachfolgenden.

Sprich: wirklich aussagekräftig wäre ein Ausschnitt, in dem der Burst 
auf PA4 hinreichend fein dargestellt wird, um zumindest die IRQs 
abzählen zu können, idealerweise auch noch eine Aussage über deren 
Abstände zulassen.

Das sollte bei der verfügbaren Gesamtauflösung problemlos möglich sein, 
wenn man schon dort die Darstellung so wählt, dass sie eben diesen Burst 
und den ersten, vielleicht auch noch den zweiten "regularen" IRQ danach 
umfasst und nicht noch etliche weitere, die dem Informationsgehalt der 
Grafik dann eigentlich nichts mehr hinzufügen.

Kann doch nicht so schwer sein, eine entsprechen Grafik zu produzieren, 
wenn man wie du die Problematik kennt und deshalb weiß, worauf es wohl 
ankommen wird.

[Peter S. (cbscpe)]

Es müsste reichen, wenn ich dir sage, dass am Anfang 4 Pulse sind.Die 
restlichen sechs siehst du ja schön. Daraus sieht man, dass in dem 
Moment in dem der Buchstabe J in den TXBUFFER geschrieben wird der USART 
damit begonnen hat den Character G zu senden. Daraus würde ich jetzt 
schliessen der TXBUFFER hat 3 Bytes. Etwas auffällig ist das die beiden 
ersten Buchstaben kurz hintereinander geschrieben werden können 
(geschrieben wird nur wen DREIF gesetzt ist) und nach einer Pause von 
4.5usec weitere zwei. Die Baudrate war übrigens 38400. Das entspricht 
der höchsten Baudrate des DLV11 Interfaces auf einer PDP-11.

[Ob S. (Firma: 1984now) (observer)]

Peter S. schrieb:

> Es müsste reichen, wenn ich dir sage

Bemüh' dich nicht weiter.

Ist halt so wie immer. Wenn du willst, das irgendwas richtig erledigt 
wird, musst du es selbst erledigen.

[Peter S. (cbscpe)]

Ich wüsste nicht, was du noch helfen könntest. Die ursprüngliche Frage 
ist immer noch nicht beantwortet, d.h. die Doku hilft nicht weiter und 
nichts Genaues weiss man nicht. Andererseits hat der TXBUFFER des AVR DB 
definitiv nicht das gleiche Verhalten wie beim ATMega. Alles deutet 
darauf hin, dass es eben nicht nur ein Byte ist sondern mehr als ein 
Byte. Da haben wir jetzt mindestens zwei Code Beispiele die vermuten 
lassen, dass es mindestens drei sind. Damit funktioniert die DLV11 
Emulation mit dem bestehenden Code vom ATMega auf dem AVR DB nicht zu 
100%. D.h. ich muss die Emulation vom DRE Interrupt auf TXC Interrupt 
umschreiben und den TXBUFFER in Software nachbilden. Und wie du richtig 
geschrieben hast, das muss ich selber erledigen. Und damit bin ich schon 
ziemlich weit gekommen. In der Zwischenzeit Bootet RT-11 vom TU-58 
Emulator über die emulierte DLV11 Schnittstelle. Mindestens mit 38400 
Baud läuft das stabil, auch wenn der TU-58 Emulator manchmal meckert. 
Wobei ich da auch schon herausgefunden habe was die DLV11 Emulation noch 
falsch macht, ist eher kosmetischer Natur, muss aber trotzdem geflickt 
werden. Danach werde ich das ganze noch etwas tunen, weil ich es mit 
mindestens 115200 Baud laufen lassen will. Das original TU-58 konnte 
zwar nur 38400 Baud, aber der TU-58 Emulator kann so schnell wie es die 
serielle Schnittstelle zulässt.

[S. L. (sldt)]

> ...dass es mindestens drei sind.

Ich verstehe die Diskussion nicht - es sind genau drei 'Stufen': zwei 
Puffer plus das Ausgaberegister, so wie es ja auch im (aktuellen) 
Datenblatt steht: 'The transmitter consists of a two-level write buffer, 
a shift register ...'.
  So weit waren wir doch schon vorgestern nachmittag.

[Volker B. (Firma: L-E-A) (vobs)]

S. L. schrieb:

> Ich verstehe die Diskussion nicht - es sind genau drei 'Stufen': zwei
> Puffer plus das Ausgaberegister, so wie es ja auch im (aktuellen)
> Datenblatt steht: 'The transmitter consists of a two-level write buffer,
> a shift register ...'.
>   So weit waren wir doch schon vorgestern nachmittag.

Das versuche ich der lieben Gemeinde seit dem Beginn dieses Threads klar 
zu machen.
Beitrag "Re: AVR128DB USART Transmit Buffer"

Ich kann mir beim besten Willen nicht vorstellen, dass der Hersteller 
(bzw. dessen Marketing) ein oder zwei weitere Speicherstellen im Fifo 
verschweigen würde.

Aber, was wäre das Leben ohne endlose Diskussionen...

Grüßle,
Volker

[Falk B. (falk)]

Volker B. schrieb:
> Das versuche ich der lieben Gemeinde seit dem Beginn dieses Threads klar
> zu machen.
> Beitrag "Re: AVR128DB USART Transmit Buffer"

Mag sein. Aber es erscheint ein wenig merkwürdig, daß man dem Sender 2 
Byte Puffer spendiert hat und dem Empfänger nur 1. Anders herum war es 
sinnvoller, denn wenn dem Sender die Daten ausgehen passiert nix 
schlimmes. Wenn der Empfänger aber nicht schnell genug lesen kann, dann 
schon.

[Peter S. (cbscpe)]

So wie es aussieht habe ich mich zu fest darauf verlassen, dass der Link 
den Google zum Datenblatt liefert richtig ist. Geht man "langsam" 
vorwärts, also Microchip.com->Prodkute->.... bis hin zum AVR128DB64 dann 
bekommt man einen anderen Link zum Datenblatt und wirklich im 
"veralteten" Datenblatt aus dem Jahre 2020 vom Google-Link steht im 
Kapitel "27.2 Overview" "The transmitter consists of a single-write 
buffer," und im Datenblatt aus dem Jahre 2023 das bei Microchip auf der 
AVR128DB64 Seite verlinkt ist steht am gleichen Ort im Kapitel "27.2 
Overview" "The transmitter consists of a two-level write buffer," aber 
diese Änderung wird in der Revision History, wie auch schon angemerkt, 
nicht erwähnt.

[S. L. (sldt)]

> Aber es erscheint ein wenig merkwürdig, daß man dem Sender
> 2 Byte Puffer spendiert hat und dem Empfänger nur 1.

?
Im Datenblatt steht doch, und wurde hier mehrfach zitiert: 'The
receiver consists of a two-level receive buffer and a shift register'.

Nur Peter Dannegger war anfangs anderer Meinung:
> Aber im Unterschied zu den standard AVRs ist der RX-Puffer
> auch nur 1 Byte groß. Die standard AVRs hatten ja noch 2
> Byte RX-Puffer.

[Veit D. (devil-elec)]

Hallo,

ich habe die Diskussion verfolgt, wollte früher antworten, habe aber 
nochmal den Logic-Analyzer angeklemmt. Ist schon 4 Jahre wo ich meine 
Usart Lib geschrieben habe. Also es ist wie ich dachte. Der alte ATmega 
verhält sich genau gleich zu den neuen µc Typen. Es gibt ein 
Daten-Register, dieses Byte wandert in das Buffer-Register und das 
wandert in das Senderegister. Es bleibt ein 3 stufiger Vorgang. Lesen 
verhält sich umgekehrt. Man selbst hat am Ende nur noch mit dem rxData 
und txData Register zu tun. Der Rest läuft entweder in der USART 
Hardware ab bzw. das nachfüllen und lesen in/aus dem Datenregister läuft 
Interrupt gesteuert im Zusammenspiel des Ringbuffers in der Lib ab. Es 
gibt kein doppeltes Buffer-Register o.ä. Ich vermute hier wird je nach 
Sprachgebrauch das Datenregister und Bufferregister zusammengefasst als 
"2 Buffer" bezeichnet. Kann man vielleicht so bezeichnen, nur dann darf 
man das Datenregister nicht unter den Tisch fallen lassen in der 
gesamten Betrachtung. Für mich gibt es nur ein Byte Buffer.

Das alles sieht man sehr schön im Analyzer.
D1 … die Zeichenfolge "4.ABCDEFG" wird gesendet, sprich in den 
Ringbuffer geschrieben
D5 … Interrupt DRE-Vector, ein Byte vom Ringbuffer wird ins 
Datenregister geschrieben
D4 … Interrupt RXC Vector, ein Byte wird vom Datenregister gelesen und 
in den Ringbuffer geschrieben
D3 … ein Byte wird aus dem Ringbuffer in ein Array geschrieben bis das 
Einlesen mit '\n' fertig ist

Man sieht auf Kanal D5, D4, D3 jeweils 10 Peaks, 9 Zeichen + '\n'.
Nachdem das erste Byte vom Datenregister, über das Bufferregister zum 
Senderegister und raus ist, empfängt RXC und direkt danach kann die 
Software aus dem Ringbuffer lesen.
Keine Verzögerung erkennbar.

[Falk B. (falk)]

Veit D. schrieb:

> Usart Lib geschrieben habe. Also es ist wie ich dachte. Der alte ATmega
> verhält sich genau gleich zu den neuen µc Typen. Es gibt ein

Na dann mach mal die Messung mit einem "alten" als ATmega 328 etc.
Ich glaube das nicht so ganz.

> man das Datenregister nicht unter den Tisch fallen lassen in der
> gesamten Betrachtung. Für mich gibt es nur ein Byte Buffer.

Nö, es sind 2, sieht man ja. Denn es werden ja durch den DRE-IRQ 3 mal 
kurz nacheinander Daten in UDR geschrieben, wovon nur das 1. im 
Schieberegister landet und gesendet wird. Die 2 anderen warten in den 2 
Pufferstufen in der Hardware.

> Senderegister und raus ist, empfängt RXC und direkt danach kann die
> Software aus dem Ringbuffer lesen.
> Keine Verzögerung erkennbar.

Das ist gar nicht das Thema und dein Ringpuffer in Software trägt nicht 
zur Klärung des Problems bei, er erschwert eher den Blick auf das 
Wesentliche.

[S. L. (sldt)]

> Also es ist wie ich dachte. Der alte ATmega verhält sich
> genau gleich zu den neuen µc Typen.

Kann ich nicht bestätigen - Senden an PC-Hyperterminal: beim ATmega48PA 
erscheint "AB", beim AVR128DB28 "ABC".

[Falk B. (falk)]

Falk B. schrieb:
> Na dann mach mal die Messung mit einem "alten" als ATmega 328 etc.
> Ich glaube das nicht so ganz.

Hier das Ergebnis mit einem ATmega328P, aka Arduino Uno.

Kanal 1 (gelb) PD1/TXD
Kanal 2 (rot)  PD2/TEST1

Man sieht, was schon immer bekannt war. Man kann in einen "leeren" UART 
lückenlos nur 2 Byte reinschreiben. Das 1. landet sofort im 
Senderegister und geht raus, das 2. landet im Sendepuffer. Erst wenn das 
1. Byte vollständig gesendet wurde, wird das. 2. Byte aus dem 
Sendepuffer ins Schieberegister geladen und das DRE Bit geht auf HIGH.
Die neuen AVRs haben anscheinend dort 2 Puffer statt bisher einem. Wofür 
auch immer.

Die Testpulse sind absichtlich so breit gemacht, damit man sie einfacher 
messen und sehen kann. Sind trotzdem nur 2 Bitzeiten.

[Peter D. (peda)]

Falk B. schrieb:
> Die neuen AVRs haben anscheinend dort 2 Puffer statt bisher einem. Wofür
> auch immer.

Ja, das ist mir auch nicht klar.
Mindestens 1 Byte Puffer ist schon sinnvoll, damit beim Senden keine 
Pausen entstehen. Größere Puffer legt man sich in der Regel als FIFO im 
SRAM an.
Und für RS-485 hat man ja extra den USART Transmit Complete Interrupt, 
um den Transceiver nicht zu früh umzuschalten.
Die Software muß also überhaupt nicht wissen, ob da nun 1 oder 2 Byte 
gepuffert werden.

[Veit D. (devil-elec)]

Hallo,

ich vergleiche das noch mit einem ATmega, dauert etwas.
Ich komme aber weiterhin nicht mit der Beschreibung und Bild von hier 
klar.
Beitrag "Re: AVR128DB USART Transmit Buffer"
Ich vermute die Beschreibung vom TO passt nicht zum Bild.
Er schreibt etwas von 4 Bytes bzw. 4 Zyklen. Ich sehe bei mir nur 3.
Seine 4 Bytes am Ende haben nichts mit warten zu tun.

Meine drei "DRE" Testpulse passen weiterhin für mich zur Beschreibung.
1. Puls
1. Byte wandert ins Datenregister.

2. Puls
1. Byte wandert in Buffer, 2. Byte ins Datenregister

3. Puls
1. Byte wandert in Shift-Register, 2. Byte in Buffer, 3. Byte in 
Datenregister

Ab jetzt wird das Datenregister im Zyklus des Shift Registern 
nachgeladen. Genau das was ich sehe. 3x kurz hintereinander, dann 
größere Lücken. Wenn es ein 2 Byte Buffer wäre, würde ich am Anfang 4 
Pulse sehen, statt 3. Soweit meine Logik.
Aktuell wette ich, dass mit "two-level write buffer" das TXDATA und 
TXBUFFER gemeint ist.

Ich melde mich wenn ich für mich Ergebnisse habe.

[Veit D. (devil-elec)]

Hallo,

ohne zu testen, mache ich noch, ist mir jetzt alles klar. Ich habe das 
Manual vom ATmega328PB und ATmega2560 gelesen. Darin ist in der 
Darstellung und Text nur vom Transmit-Buffer und Shift-Register die 
Rede. Wäre quasi eine 1 Level Buffer. Ein echten Zwischenbuffer gibt es 
nicht. Deswegen sieht Falk nur 2 Peaks beim Test.

ATmega328PB + ATmega2560 Manual:
"A data transmission is initiated by loading the transmit buffer with 
the data to be transmitted. The CPU can load the transmit buffer by 
writing to the UDRn I/O location. The buffered data in the transmit 
buffer will be moved to the Shift register when the Shift register is 
ready to send a new frame."

Also wie ich vermutete, beim AVRxDB u.ä. ist mit "2 Level Buffer" das 
Transmit und Buffer Register gemeint. Auch genauso wie es in deren 
Manuals grafisch dargestellt wird. Es sind 3 Register statt 2 
dargestellt. Das Buffer-Register gibt es beim ATmega328PB + ATmega2560 
u.ä. nicht.

Kurzform:

ATmega328PB, ATmega2560 u.ä. haben:
ein Daten-Register und ein Shift-Register. Daten-Register wird auch als 
Datenbuffer bezeichnet.

AVRxDB u.ä. haben:
ein Daten-Register, ein Buffer-Register und ein Shift-Register.

Also 2 Register vs. 3 Register.

Edit:
Was ich natürlich fast zurücknehme bzw. korrigiere ist, dass sich beide 
Controllertypen gleich verhalten. Der Unterschied ist der neue 1 Byte 
Buffer der AVRxDB Typen. Das Verhalten nach außen ist schon gleich, weil 
das bei der Programmierung und Anwendung keine Rolle spielt, weil man 
mit dem neuen Buffer-Register gar nicht in Berührung kommt. Das arbeitet 
unauffällig im Hintergrund.

[Achim H. (pluto25)]

Veit D. schrieb:
> Das Verhalten nach außen ist schon gleich, weil
> das bei der Programmierung und Anwendung keine Rolle spielt

Was übersehen wir da?
Ich setze mal voraus das der Hersteller sich dabei was gedacht hat oder 
auf Kundenwüsche reagiert?
Gibt es Anwendungen bei dehnen das weitere Byte sinnvoll/spürbar besser 
ist?

[Peter D. (peda)]

Achim H. schrieb:
> Gibt es Anwendungen bei dehnen das weitere Byte sinnvoll/spürbar besser
> ist?

Man könnte im SPI-Mode 3 * 74HC595 in einem Rutsch beschreiben. Nur 
gewinnt man dabei nichts. Der Latchpuls muß trotzdem warten, bis alles 
gesendet wurde.

[Nemopuk (nemopuk)]

Achim H. schrieb:
> Gibt es Anwendungen bei dehnen das weitere Byte sinnvoll/spürbar besser
> ist?

Z.B wenn interrupts zeitweise gesperrt sind, oder wenn der CPU Takt vs. 
UART Takt niedrig ist, so daß der Aufruf der ISR (prolog/epilog) länger 
dauert, als ein Byte zu senden.

[Veit D. (devil-elec)]

Hallo,

für das Senden sehe ich das nicht kritisch. Der Empfänger wartet 
sowieso. ;-)
Beim Empfangen könnte es helfen, um Datenverlust zu vermeiden, wenn im 
seltenen Fall irgendwie kurz keine Zeit vorhanden ist, um das 
Datenregister auszulesen. Das "keine Zeit" darf natürlich nicht der 
Normalfall sein, dann hilft kein Buffer der Welt, irgendwann wäre jeder 
Buffer voll. Der zusätzliche Buffer könnte jedenfalls helfen um 
irgendeine längerdauernde "Wartezeit" zu überbrücken. Ist ein Gimmick, 
nimmt man gern mit. :-)

Was richtig cool wäre, wenn ein Ringbuffer in Hardware vorhanden wäre. 
256 Bytes sollten reichen.  :-)

[Falk B. (falk)]

Veit D. schrieb:
> Beim Empfangen könnte es helfen, um Datenverlust zu vermeiden, wenn im
> seltenen Fall irgendwie kurz keine Zeit vorhanden ist, um das
> Datenregister auszulesen.

Naja, die Puffer müssen halt die Maximalzeit von anderen, aktiven 
Interrupts und Interruptsperren in atomaren Sequenzen überbrücken. Die 
kann man relativ genau messen bzw. berechnen. Und bei sehr hohen 
Baudraten müssen die halt recht kurz sein. 250kBaud bei DMX512 sind halt 
nur 44us/Byte. Gemäß dem alten Spruch an Telefonzellen "Fasse dich kurz, 
denke an deinen UDRE-Interrupt." ;-)

[Veit D. (devil-elec)]

Hallo,

genau.

[Harald K. (kirnbichler)]

Die PC-Standard-UART 8250/16450 wurde in den späten 80er Jahren durch 
die 16550 ergänzt, die 16 Bytes Sende- und Empfangs-FIFO mitbrachte. Das 
half bei hohen Datenraten enorm, die Interruptlast zu reduzieren. Die 
Füllstandsschwelle, ab der ein Interrupt ausgelöst wurde, war 
programmierbar (1, 4, 8 oder 14 Byte). IBM setzte diese UART in der 
PS/2-Serie ein, da die UART auf ISA-Karten oft gesockelt war, und 16550 
pinkompatibel zu den Vorgängern war, haben damals (in der vorderen 
Altsteinzeit) einige Leute ihre UARTs auch in XTs und ATs getauscht, um 
davon zu profitieren.

Erstaunlich, daß so etwas in Microcontrolleranwendunge so vollkommen 
ungewöhnlich ist.

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:
> wurde in den späten 80er Jahren durch
> die 16550 ergänzt, die 16 Bytes Sende- und Empfangs-FIFO mitbrachte.
[...]
> Erstaunlich, daß so etwas in Microcontrolleranwendunge so vollkommen
> ungewöhnlich ist.

Nun, ein Interrupt ist halt bei heutigen µC i.A. sehr viel billiger, als 
sie es damals bei den 8086, 80286 und 80386 war.

Schau dir doch z.B. einen AVR8 an. Die Dinger laufen (offiziell) mit bis 
zu 24MHz. Ein minimaler Interrupt für UART-RX->FIFO braucht mit allem 
Overhead ca. 16Takte.

Vergleiche das mal mit der Sachlage bei der PC/AT-Architektur.

[Norbert (der_norbert)]

Harald K. schrieb:
> Erstaunlich, daß so etwas in Microcontrolleranwendunge so vollkommen
> ungewöhnlich ist.

Das mag daran liegen, dass nur 16 Byte FIFO, also, na ja…

Deshalb hat man zB. in den 99ct µC der RP2xxx Serie gleich 32 Bytes zum 
Senden und 32 Halfwords zum Empfangen implementiert.
Pro UART. Plus DMA. 😎

[Harald K. (kirnbichler)]

Ob S. schrieb:
> Vergleiche das mal mit der Sachlage bei der PC/AT-Architektur.

Sicher, aus heutiger Sicht wurden die Dinger mit Gleichstrom getaktet.

Norbert schrieb:
> Das mag daran liegen, dass nur 16 Byte FIFO, also, na ja…

Spätere Varianten hatten deutlich größere Fifos, so z.B. in Form von 
OXPCIE952. Da warens dann schon 128 Byte.

[Veit D. (devil-elec)]

Hallo,

zur Vollständigkeit. Habe das gleiche Ergebnis mit ATmega328PB wie Falk 
mit seinem ATmega328P. Wäre auch komisch gewesen wenn es anders wäre. 
;-) Alle Controller verhalten sich wie im Manual beschrieben. Dank fürs 
Zuhören.