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.