Guten Morgen, da wir keine Atmega16 auftreiben können und jede Menge Atmega32 am Lager haben war die Überlegung die Atmega32 zu verwenden. Leider habe ich für diese Baugruppe keinen Quellcode mehr. Ist es möglich das Hexfile so anzupassen das es für den Atmega32 passt? Danke für die Hilfe
Ist es möglich das Hexfile so anzupassen das es für den Atmega32 passt? Danke für die Hilfe
Im Prinzip schon, der wesentliche Unterschied ist die Interrupttabelle. Die muss man manuell anpassen. Der Rest ist identisch.
HEX-File im HEX-Editor laden, ändern, wieder speichern. Kann man auch direkt als ASCII editieren, muss dann aber die Prüfsummen der Zeilen neu berechnen.
Spontan würde ich sagen, das ist ohne Änderung möglich - einfach mal ausprobieren.
Ohne den Code zu disassemblieren, geht das nicht. Man weiß ja nicht, was ist Code und was sind Daten. Wenn man die zu ändernden Stellen gefunden hat, kann man die natürlich im Hexfile patchen. Beitrag "Re: was ist der unterschied zwischen dem atmega16 und dem atmega32"
Mein_erstes_Mal schrieb:
Ist es möglich das Hexfile so anzupassen das es für den Atmega32 passt? Danke für die Hilfe
Im Prinzip schon, der wesentliche Unterschied ist die Interrupttabelle. Die muss man manuell anpassen. Der Rest ist identisch.
HEX-File im HEX-Editor laden, ändern, wieder speichern. Kann man auch direkt als ASCII editieren, muss dann aber die Prüfsummen der Zeilen neu berechnen.
Wie findet man die Interrupttabelle? Danke für die Hilfe
Spontan würde ich sagen, das ist ohne Änderung möglich - einfach mal ausprobieren.
Nein ohne Änderung geht es nicht
Wie findet man die Interrupttabelle?
Steht direkt am Anfang des Programms.
da wir keine Atmega16 auftreiben können und jede Menge Atmega32 am Lager haben war die Überlegung die Atmega32 zu verwenden.
Kein Problem, das Hex läuft unverändert. Der überschüssige Flash und SRAM bleibt unbenutzt. Lediglich ein Bootloader müßte auf die neue Startadresse compiliert werden.
Kein Problem ...
Ja, das dachte ich auch - da haben wir beide Atmels Frühzeit überschätzt; s. Mario M.s Beitrag.
Ja, das dachte ich auch - da haben wir beide Atmels Frühzeit überschätzt; s. Mario M.s Beitrag.
Ja, Punkt 4 und 5 könnten kritisch sein. Ich heb ja immer den Quelltext auf, dann muß man nur das Target umstellen.
Ist es möglich das Hexfile so anzupassen das es für den Atmega32 passt?
Nach Assembler disassemblen, und auf die kritischen Punkte hin prüfen. Ist halt etwas Aufwand.
Oliver
Nach Assembler disassemblen, und auf die kritischen Punkte hin prüfen. Ist halt etwas Aufwand.
Problem ist, der Disassembler weiß nicht, was ist Code und was konstante Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen. Ich würd mal sagen, ohne Quellcode, vergiß es.
Mein_erstes_Mal schrieb:
da wir keine Atmega16 auftreiben können und jede Menge Atmega32 am Lager haben war die Überlegung die Atmega32 zu verwenden.
Kein Problem, das Hex läuft unverändert. Der überschüssige Flash und SRAM bleibt unbenutzt. Lediglich ein Bootloader müßte auf die neue Startadresse compiliert werden.
Bist du sicher? Danke für die Hilfe
Problem ist, der Disassembler weiß nicht, was ist Code und was konstante Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen. Ich würd mal sagen, ohne Quellcode, vergiß es.
Das hat bei uns an der Hochschule mal ein Student gemacht: es war sehr mühselig, aber er hat es geschafft! Das Ganze wurde dann eine Diplomarbeit...
Bist du sicher?
Jetzt nicht mehr, siehe: Beitrag "Re: was ist der unterschied zwischen dem atmega16 und dem atmega32"
Es sind einige Interrupts hinzu gekommen und damit verschieben sich alle nachfolgenden. Es kann aber durchaus sein, daß Dein Programm keine Interrupts benutzt. Man kann auch alle Interruptquellen in der Mainloop pollen.
Die Interruptsprungtabelle zu bearbeiten sollte möglich sein. Wenn das Programm aber Sleep-Modi verwendet, dann wird es schwierig.
Problem ist, der Disassembler weiß nicht, was ist Code und was konstante Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen. Ich würd mal sagen, ohne Quellcode, vergiß es.
Das hat bei uns an der Hochschule mal ein Student gemacht: es war sehr mühselig, aber er hat es geschafft! Das Ganze wurde dann eine Diplomarbeit...
Solange kein Bootlader vorhanden ist, ist es in diesem Fall einfacher. Es muss nur die Interrupt Vektor Tabelle anders sortiert werden und falls das MCUCR Register benutzt wird, müssen da eventuell zwei Bits getauscht werden.
Ich schätze den Aufwand für einen Test auf weniger als einen halben Tag. Einen Versuch ist es wert.
Problem ist, der Disassembler weiß nicht, was ist Code und was konstante Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen. Ich würd mal sagen, ohne Quellcode, vergiß es.
Ich habs schon gemacht. Ja, es ist teilweise mühsam, aber nicht unmöglich. Letztendlich muß man ja nur die Interrupttabelle und eben die Zugriffe auf MCUCR prüfen.
Oliver
Das sind alles Fragen, auf die niemand eine Antwort weiß. Der TE wahrscheinlich auch nicht.
Ich würde gerne wissen - falls das bekanntgegeben werden kann - was macht der Controller bzw. das Programm und wie groß ist die .hex-Datei? Ist bekannt, ob das Ding einen Bootloader benutzt (erkennt man an den Fuses, die müssten ja bekannt sein wenn das Ding programmiert wird).
Das Disassemblieren solcher Programme ist nicht ganz so schwer wie bei PC-Programmen, da im Flash nur statische Daten liegen. Man kriegt also recht schnell raus, was Code ist und was Daten. Wenn das Programm übersichtlich geschrieben wurde, dann liegen die Daten alle am Ende. Außerdem sind alle Befehle außer JMP/CALL und LDS/STS exakt 16 Bit lang (die beiden Ausnahmen sind 32 Bit lang).
Die Interruptsprungtabelle zu bearbeiten sollte möglich sein.
Das reicht aber nicht. Durch die größere Vectortabelle verschieben sich auch sämtliche anderen Jumps, Calls und Arrays im Code. Nur RJMP und RCALL könnten nicht betroffen sein.
... größere Vectortabelle ...
? Sind doch beide Male 21 Vektoren?
Sind doch beide Male 21 Vektoren?
Ja, Du hast Recht. Die sind nur umsortiert, nehme also alles zurück. Alle Ziele bleiben an ihrer Adresse.
... größere Vectortabelle ...
? Sind doch beide Male 21 Vektoren?
Wers offiziell nachlesen will, Microchip Appnote AVR089
https://ww1.microchip.com/downloads/en/Appnotes/doc2538.pdf
Oliver
Alle Ziele bleiben an ihrer Adresse.
Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und die Rjumps umrechnen.
Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und die Rjumps umrechnen.
und das kann man im Hexfile machen? Danke für die Hilfe
und das kann man im Hexfile machen?
Ja, wenn man die Interrupttabelle findet, und weiß, wie so ein hexfile aufgebaut ist, und die Prüfsummen selber berechnen kann, dann ja.
Also eher nein.
Da die Interrupttabelle aber am Anfang des flashs steht, kann man die Interrupttabelle einzeln aus dem alten hexfile disassemblieren, dann ändern, und daraus ein neues hexfile erstellen lassen. Damit dann die entsprechenden Zeilen im alten überschreiben. Gibts dazu noch einen bootloader, muß man da auch noch nachschauen.
Wenn dir das alles gar nichts sagt, dann wird es Zeit, jemanden bei euch mit dem Problem zu beauftragen, der sich damit auskennt.
Oliver
Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und die Rjumps umrechnen.
und das kann man im Hexfile machen? Danke für die Hilfe
Ja. Man muss nur die JMPs an die richtige Stelle schieben und die NOPs oder JMPs auf die leere ISR (bad ISR) verschieben. Lad dein Hexfile mal hier hoch.
Ja, wenn man die Interrupttabelle findet, und weiß, wie so ein hexfile aufgebaut ist, und die Prüfsummen selber berechnen kann, dann ja.
Kann man. Denn das Hexfile ist Intel-HEX und damit einfach.
Also eher nein.
Wollen wir wetten?
Mein_erstes_Mal schrieb:
Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und die Rjumps umrechnen.
und das kann man im Hexfile machen? Danke für die Hilfe
Ja. Man muss nur die JMPs an die richtige Stelle schieben und die NOPs oder JMPs auf die leere ISR (bad ISR) verschieben. Lad dein Hexfile mal hier hoch.
Da File ist hier. Danke für die Hilfe
Da File ist hier.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Das ist der Anfang der Datei, die Interrupttabelle. der erste Eintrag in der ersten Zeile ist 0C947300. Vorsicht, das ist durch die little Endian Maschine AVR ziemlich verdreht! Als big endian ausgeschrieben heißt das
94 0C 00 73
Wenn man das gemäß AVR Instruction Set dekodiert, ist das ein
JMP $73
Dort fängt das Programm nach dem Reset an.
Der nächste und viele andere Einträge sind 0C949000, big endian
94 0C 00 90 bzw.
JMP $90
Das sind die ungenutzten Interrupts. Die springen alle auf eine leere ISR, die meist einen Softwarereset auslöst, wenn diese im Programm durch einen Fehler aktiviert werden.
Die letzten beiden Ziffern der Zeile sind die Prüfsumme, keine Programmdaten Folgende Einträge weichen ab
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
Beim ATmega 32 liegen die Verktoren anders
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
Damit sieht die neue Interrupttabelle als Intel-HEX so aus
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Die Püfsummen der geänderten zeilen kann man hier leicht berechnen lassen.
https://www.fischl.de/hex_checksum_calculator/
Dazu muss man nur die Zeile mit zusätzlichen 00 eintragen und Analyze drücken. Die Seite spuckt dann die korrekte Prüfsumme aus, die man eintragen kann.
Im Anhang die neue Datei, probier mal.
Beim ATmega 32 liegen die Verktoren anders
Soweit ich das richtig verstehe, sind die Jumps relativ. Wenn sich der Ort des Vektors um einen Offset verschiebt, müssen sich die Sprungwerte ebenso um diesen Offset vergrößeren/verkleinern?
Du schreibst jedoch dieselben Jump-Werte nur an die andere Stelle, wenn ich Deinen Beitrag richtig verstanden habe.
Soweit ich das richtig verstehe, sind die Jumps relativ.
Nö. Es sind ja JMP, absolute Sprünge im 4M Adressraum. Ein RJMP ist relativ, Nomen est Omen! Die gibt es aber nur bei kleinen AVRs mit max. 8k Flash. Z.B. ATmega88
Ein RJMP ist relativ, Nomen est Omen! Die gibt es aber nur bei kleinen AVRs mit max. 8k Flash.
Je nach Optimierung darf der AVR-GCC auch bei den großen RJMP benutzen und tut dies auch, wenn das Ziel innerhalb +/-4kB ist. In der Vectortabelle benutzt er aber nur JMP, also muß nichts umgerechnet werden.
Also eher nein.
Wollen wir wetten?
Die Antwort galt nicht für dich. Das du das für den TO machen wirst, war eh klar.
Oliver
Mein_erstes_Mal schrieb:
Da File ist hier.
********************************:100000000C9473000C9490000C9490000C9490004D :100010000C9490000C9490000C9490000C94900020 :100020000C9490000C9428090C9490000C94020FEE :100030000C94410F0C9490000C9490000C94900040 :100040000C9490000C9490000C9490000C949200EE :100050000C9490003F01410143012B012D012F0120
Das ist der Anfang der Datei, die Interrupttabelle. der erste Eintrag in der ersten Zeile ist 0C947300. Vorsicht, das ist durch die little Endian Maschine AVR ziemlich verdreht! Als big endian ausgeschrieben heißt das
Im Anhang die neue Datei, probier mal.
Ich muss mir das erst heute Abend ansehen. Im Moment gucke ich wie das Schwein ins Uhrwerk. Fettes Danke schon jetzt ich gebe Feedback
Guten Morgen Falk B.
Ich habe es mir angesehen und ich staune. Funktionieren tut es noch nicht. Das Atmelstudio mekert das die Prüfsumme nicht stimmt.
Ich versuche später ob ich den Fehler finde
Danke für die Hilfe
Angehängte Dateien:
-
at32.jpg
(130 KB)
Das Atmelstudio mekert das die Prüfsumme nicht stimmt.
Ich versuche später ob ich den Fehler finde
Soll das Satire sein?
Und zum eigentlichen Probelem: Entweder das Ding läuft ohne Änderung auf einem binärkompatiblen Controller oder du compilierst es neu. Alles andere ist Pfusch und wird gerade dir nicht gelingen.
Funktionieren tut es noch nicht. Das Atmelstudio mekert das die Prüfsumme nicht stimmt.
Zeile 3 ist falsch. Die lautet richtig: :100020000C9490000C9490000C9492000C9428096D
Oliver
Angehängte Dateien:
-
2023-05-25_08_30_10-Window.png
(5,1 KB)
Soll das Satire sein?
Nein überhaupt nicht. Ich dachte mir das wenn ich jetzt die Anleitung von Falk habe das ich es vielleicht auch selbst schaffe.
Wollte nur die Hilfsbereitschafft nicht überstrapazieren.
Zeile 3 ist falsch. Die lautet richtig: :100020000C9490000C9490000C9492000C9428096D
Hmm, hab mich schon gewundert, warum zweimal FF als Prüfsumme rausgekommen ist. Hab vermutlich zweimal die gleiche Zeile kopiert. 8-0
Habe jetzt das Angepasste File ausprobiert. Es ist so das anscheinend der Rx Uart Interrupt nicht so läuft wie er soll.
Kann das sein?
Flash doch aus Spaß mal die unveränderte Datei. Mich und bestimmt noch andere mit dem gleichen Problem würde interessieren, ob das funktioniert oder nicht.
Beitrag #7420749 wurde von einem Moderator gelöscht.
Es ist so das anscheinend der Rx Uart Interrupt nicht so läuft wie er soll.
Wie erkennst du das?
Kann das sein?
Möglich, vielleicht habe ich einen Fehler gemacht.
Möglich, vielleicht habe ich einen Fehler gemacht.
Er könnte die Interruptvektortabelle jetzt ja auch einfach nochmal nachprüfen.
Beitrag #7420759 wurde von einem Moderator gelöscht.
Habe jetzt das Angepasste File ausprobiert. Es ist so das anscheinend der Rx Uart Interrupt nicht so läuft wie er soll.
Kann das sein?
Hast mal in die App Note reingeschaut?
Wers offiziell nachlesen will, Microchip Appnote AVR089
Da siehst du in der Tabelle, dass die UART RX Vektoren an anderer Stelle sind.
Wie erkennst du das?
Kann das sein?
Möglich, vielleicht habe ich einen Fehler gemacht.
Hallo Falk, ich gehe davon aus das es mit dem Empfang an der Uart ein Problem gibt. Sobald ich daten vom Pc zum Display sende macht das Display nichts mehr.
Deshalb meine Mutmaßung das es am Rx Uart liegen könnte. Danke für die Hilfe
Flash doch aus Spaß mal die unveränderte Datei. Mich und bestimmt noch andere mit dem gleichen Problem würde interessieren, ob das funktioniert oder nicht.
Habe ich bereits vor ich hier geschrieben habe. Beitrag "Re: Hex File von Atmega16 in Atmega32 verwandeln"
ich gehe davon aus das es mit dem Empfang an der Uart ein Problem gibt. Sobald ich daten vom Pc zum Display sende macht das Display nichts mehr.
Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.
Falls RX mit Interrupt läuft. Hast das mal geprüft (siehe Bild)?
Angehängte Dateien:
-
16_32.png
(150 KB)
Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.
Wundert mich - wenn ich es richtig sehe, wurde lediglich versehentlich 'SPI STC' zusätzlich belegt.
Oliver S. schrieb:
Wers offiziell nachlesen will, Microchip Appnote AVR089
Da siehst du in der Tabelle, dass die UART RX Vektoren an anderer Stelle sind.
Und was glaubst du, was hier gemacht wurde?
Möglich, vielleicht habe ich einen Fehler gemacht.
Hallo Falk, ich gehe davon aus das es mit dem Empfang an der Uart ein Problem gibt. Sobald ich daten vom Pc zum Display sende macht das Display nichts mehr.
Und was macht es vorher?
Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.
Scheint so. Hast du die AVR Fuses richtig eingestellt? Die stehen nämlich nicht im HEXfile.
Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.
Falls RX mit Interrupt läuft. Hast das mal geprüft (siehe Bild)?
Ja, haben wir!
OK, Fehler gefunden, ich war bei den UART Vektoren um eine Nummer verrutscht!
OK, Fehler gefunden, ich war bei den UART Vektoren um eine Nummer verrutscht!
Jetzt rennt es wie es soll👏🏾👏🏾👏🏾👏🏾👏🏾👏🏾 Wow ich staune mega fettes Danke!!! kann ich dir ein Bier spendieren??
Wers offiziell nachlesen will, Microchip Appnote AVR089
Sind die bei Atmel betrunken gewesen? Warum verwürfelt man die Interrupttabelle, wenn die Anzahl und Art der Interrupts gleich bleibt? Nur wegen der Pseudo-Priorität, wenn zwei Interrupts gleichzeitg aktiv werden? Cmon! Ebenso die beiden Bits in MCUSR? Wir werden es nie erfahren . . .
Ein RJMP ist relativ, [...] Die gibt es aber nur bei kleinen AVRs mit max. 8k Flash. Z.B. ATmega88
Nö, RJMP / RCALL wird von allen AVR cores unterstützt.
Bei Flash > 8KiB gibt's dann zusätzlich noch JMP / CALL, wobei diese Instruktionen bei manchen neueren Devices (zB 0-Series) auch schon bei Flash <= 8KiB unterstützt werden.
Das Problem mit RJMP / RCALL im Kontext der Frage ist, dass diese bein Setzen des neuen PC einen Wrap-Around machen. Negativ erscheinende Zieladressen sind also ok, landen beim ATmega16 aber an einer anderen Stelle als beim ATmega32.
Falk B. schrieb:
Ein RJMP ist relativ, [...] Die gibt es aber nur bei kleinen AVRs mit max. 8k Flash. Z.B. ATmega88
Nö, RJMP / RCALL wird von allen AVR cores unterstützt.
Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht die Vektortabelle aus RJMPs.
Beitrag #7421748 wurde von einem Moderator gelöscht.
Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht die Vektortabelle aus RJMPs.
Das ist falsch. Bei diesen Teilen muss sie zwingend aus RJMPs bestehen, weil halt die Vektoren dort nur ein Wort groß sind. Bei den größeren sind sie zwei Worte groß. Dort hat man die Wahl, ob man JMPs oder RJMPs verwendet, naja, natürlich nur, wenn das Sprungziel im per RJMP erreichbaren Teilbereich des Flash liegt.
Genau genommen, müssen nichtmal zwingend überhaupt Sprungbefehle auf den Vektoren liegen. Es ist nur in den meisten Fällen sinnvoll.
Bei diesen Teilen muss sie zwingend aus RJMPs bestehen, weil halt die Vektoren dort nur ein Wort groß sind. Bei den größeren sind sie zwei Worte groß.
Da verwechselt der der große c-hater dann doch Ursache und Wirkung. Der eigentliche Grund, warum die bei den Teilen aus rjmps bestehen MUSS, ist einfach der, daß es kein jmp gibt. Und daher ist dann auch die Sprungtabelle passend aufgebaut.
Oliver
Da verwechselt der der große c-hater dann doch Ursache und Wirkung.
Nein. Die Behauptung von Falk B. war:
Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht die Vektortabelle aus RJMPs.
Und das ist schlicht falsch. Man beachte das Wörtchen "nur".
Tatsache ist, dass sie eben auch bei größeren AVR8 durchaus aus RJMPs bestehen kann. Darauf wollte ich im Kern nur hinweisen.
Nein. Die Behauptung von Falk B. war:
Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht die Vektortabelle aus RJMPs.
Und das ist schlicht falsch. Man beachte das Wörtchen "nur".
Tatsache ist, dass sie eben auch bei größeren AVR8 durchaus aus RJMPs bestehen kann. Darauf wollte ich im Kern nur hinweisen.
Nein, du verstehst das nicht richtig.
AVR8 mit grösser als 8kb Flash haben eine Vektortabelle mit 32 Bit pro Eintrag. Alles kleinere hat eine Tabelle mit 16 Bit pro Eintrag. Ergo kann alles was 8k oder kleiner ist NUR RJMP, die anderen JMP oder wenn man möchte auch RJMP, falls die relative Reichweite +2k -2k reicht. Dann bleiben die beiden letzten Bytes ebend unbenutzt.
AVR8 mit grösser als 8kb Flash haben eine Vektortabelle mit 32 Bit pro Eintrag. Alles kleinere hat eine Tabelle mit 16 Bit pro Eintrag. Ergo kann alles was 8k oder kleiner ist NUR RJMP, die anderen JMP oder wenn man möchte auch RJMP, falls die relative Reichweite +2k -2k reicht. Dann bleiben die beiden letzten Bytes ebend unbenutzt.
Ja, genau so ist das.
Interessant ist wäre nur, wie du zu der Aussage kommst, dass ich da etwas nicht verstanden hätte...
Denn genau das hatte Falk B. geleugnet und ich richtig gestellt.
Wenn also irgendwer etwas nicht verstanden hat, dann du...
Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht die Vektortabelle aus RJMPs.
Und das ist schlicht falsch. Man beachte das Wörtchen "nur".
Du zweifelst an dieser Aussage.
Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht die Vektortabelle aus RJMPs.
Und das ist schlicht falsch. Man beachte das Wörtchen "nur".
Du zweifelst an dieser Aussage.
Natürlich. Die offensichtliche und unbestreitbare Tatsache, dass halt auch bei einem größeren AVR8 die Vektortabelle aus lauter RJMPs bestehen kann, beweist nach den Gesetzen der Logik, dass die Aussage von Falk B. schlicht falsch sein muss.
Tatsache ist, dass sie eben auch bei größeren AVR8 durchaus aus RJMPs bestehen kann. Darauf wollte ich im Kern nur hinweisen.
Geht dir jetzt besser? Ist dir einer abgegangen? Bravo! Was wäre die Welt ohne Menschen wie du?
In den ersten Datenblättern des ATmega8 waren JMP und CALL noch aufgeführt und wurden korrekt ausgeführt. Quasi der CPU-Core des ATmega16.
In den ersten Datenblättern des ATmega8 waren JMP und CALL noch aufgeführt und wurden korrekt ausgeführt. Quasi der CPU-Core des ATmega16.
Ich konnte das kaum glauben, ist aber tatsächlich so (siehe Anhang). Tja, man lernt immer noch dazu.
Angehängte Dateien:
-
Changes.png
(18 KB)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.