|
Anzeige
|
AVR128DB USART Transmit BufferIm 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
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 :
Bearbeitet durch User
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.
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.
Sicher? Oder nur eine schlechte Programmierung im Original, welche, warum auch immer, jetzt fehlschlägt. Was geht denn nicht? 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.
Das DB sagt was anderes (Abschnitt 25.2):
Nein. Aber es gibt ein offizielles Statement im DB, was besagt, dass es eben nur ein Byte ist (Abschnitt 25.2):
Also eigentlich alles genau so wie bei den Classic-Megas (und den wenigen Classic-Tinys mit UART).
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
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. 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.
Angehängte Dateien:
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. Im Zweifelsfall programmiert man sich ein kleines Testprogramm mit ein paar Testpins und mißt mit dem Oszi, was abgeht. 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.
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.'
D.h.: auch die aktuellen Datenblätter stimmen nicht!
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.
Stimmt: zweimal 'rjmp pc+1', also 4 Takte, zwischengeschaltet, erscheint "ABC". 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)
Angehängte Dateien:
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.
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?
Natürlich als *.png, nicht als *.jpg... 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.
Angehängte Dateien:
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. 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.
Bemüh' dich nicht weiter. Ist halt so wie immer. Wenn du willst, das irgendwas richtig erledigt wird, musst du es selbst erledigen. 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.
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
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. 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.
? 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:
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.
Angehängte Dateien:
Na dann mach mal die Messung mit einem "alten" als ATmega 328 etc. Ich glaube das nicht so ganz.
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.
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.
Kann ich nicht bestätigen - Senden an PC-Hyperterminal: beim ATmega48PA erscheint "AB", beim AVR128DB28 "ABC".
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.
Angehängte Dateien:
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. 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.
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. :
Bearbeitet durch User
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. :
Bearbeitet durch User
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?
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.
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. 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. :-)
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." ;-)
Angehängte Dateien:
Hallo, genau. 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.
[...]
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.
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. 😎
Sicher, aus heutiger Sicht wurden die Dinger mit Gleichstrom getaktet.
Spätere Varianten hatten deutlich größere Fifos, so z.B. in Form von OXPCIE952. Da warens dann schon 128 Byte. 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.
Angehängte Dateien:
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
