www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Harvard vs. Von Neumann


Autor: Stefan Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo

meine frage hier soll jetzt nicht sein, welche von den beiden
architekturen besser/schlechter ist!

ich möchte nur konktret wissen, was mit der von neumann architektur
besser(oder überhaupt erst) zu realisieren ist als mit der harvard
architektur bzw umghekehrt, und wo die vor und nachteile liegen(zb
programmierung)!

und das alles natürlich im bezug auf mikrocontroller =)

hoffe ihr könnt mir helfen

mfg Stefan

Autor: Gehard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Programmierung gibt es überhaupt keinen Unterschied. Die beiden
Architekturen unterscheiden sich darin, daß bei der von Neumann
Architektur Befehle und Operanden im gleichen Speicher stehen und zum
Lesen dieser 2 Lese-Zyklen der CPU notwendig sind. Bei der
harvard-Architektur hat die COU 2 getrennte Busse über die 2 getrennte
Speicher gleichzeitig adressiert werden. Damit kann dann die CPU den
Befehl und den dazugehörigen Operanden gleichzeitig lesen. Unser guter
PC zuhause hat - wenn es zumindest ein Pentium-Prozessor ist beides
vereint: Wenn die CPU auf den hauptspeicher zugreift, arbeitet die CPU
mit der herkömmlichen von Neumann-Architektur, und wenn die CPU mit
ihrem internen primären Cache arbeitet, arbeitet sie mit einer
Harvard-Architekur.

Der Vorteil der von Neumann Atrchitektur ist, daß man nur halb so viele
Leitungen und CPU-Anschlüsse braucht wie bei der Harvard-Architektur,
NAchteil die CPU muß zum Lesen eines Befehks, der einen Operanden hat,
2 Mal auf den Speicher zugreifen.

Vorteil der Harvard-Architektur ist, daß der Befehl und der Operand
geichzeitig gelesen werden kann.

Gerhard

Autor: Stefan Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also erstmal danke für die schnelle antwort!

vllt habe ich nicht klar ausgedrückt worauf ich hinaus will,
entschuldigung dafür ^^
ich weis prinzipiell wo der unterschied zwischen von neumann und
harvard leigt, nämlich in den punkten die du oben so ausführlich
beschrieben hast =)
aber diese punkte sind für mich als endanwender nicht relevant!
mir geht es darum wo für mich die vor- und nachteile als benutzer
liegen!

wenn bei der programmierung kein unterschied ist, und mir die anzahl
der leitungen etc. egal sein können, ist es dann für mich bei der wahl
des uC überhaupt wichtig ob ich eine harvard oder von neumann
architektur wähle bzw bemerke ich den unterschied überhaupt ?!

soweit ich weis sind PICs immer Harvard architekturen und da ich diese
schon benutzt habe kenn ich mich auch damit aus.

aber wie funktioniert die aufteilung des speichers bei einem uC mit von
neumann architektur?
wenn daten und befehle im gleichen speicher stehen, ist dann der
gesamte speicher ein Flash?
wenn ja, würde das den uC doch erheblich verlangsamen?!
oder ist dann der gesammt speicher ein RAM?
wo wird dann das programm abgespeichert? in einem seperaten
programmspeicher, aus dem dann das programm in den RAM geladen wird?
oder wird das programm im seperaten speicher gelassen und direkt von
dort aus benutzt? wobei dann wieder kein direkter unterschied zur
harvard architektur vorhanden wäre?

also mal sorry dass so viele fragen kommen =)

was ich so weit mitbekommen habe würde sich die harvard architektur für
systeme die mehrere programme ausführen sollen(zb. programmierbare
taschenrechner) nicht eigenen, da nur befehle aus dem programmspeicher
ausgelesen werden können, also keine externen programme geladen werden
können.richtig ? =)
dies wäre ein großer vorteil der von neumann architektur!
aber worin liegt dann der vorteil von harvard, wenn nicht in der
einfacheren programmierbarkeit?

danke schon mal

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bei der von Neumann Architektur gibt es natürlich auuch RAM und ROM
bereiche, in diesen Bereichen kann halt alles liegen was man braucht.
Sowohl Programm als auch Daten. Befehle und Operanden werden dann
Sequentiell aus dem Speicher gelesen. Das ist natürlich etwas
langsamer, macht aber meistens nichts. Intern ist es dem anwender ja
egal aber bei externem Speicher hat eigentlich keiner mehr lust auf
Harvard Architektur. Die Busse müssen halt doppelt vorhanden sein und
das kostet doppelt soviele Pins. Manche MC´s regeln den Zugriff auf
Daten oder Programm dann über einen Separaten Pin aber dann ist es mit
dem Parallelen Zugriff auch wieder vorbei. Der Vorteil bei von Neumann
ist einfach das man den vorhandenen Speicher für alles nutzen kann. Es
kann nicht passieren das noch jede Menge Datenspeicher vorhanden ist
aber der Progarmmspeicher aus alle nähten platzt. Es kann auch sehr von
Vorteil sein wenn es um das Thema Bootloader geht, hier sind die Daten
ja wenig später auf einmal Programm. Sowas geht mit einer echten
Harvard Architektur nicht.


Eckhard

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Als Anwender merkst du wohl praktisch keinen Unterschied. Ich kann,
wenn ich in einem Auto sitze, auch nicht sagen, ob es mit Benzin oder
Diesel läuft.

Mein kleiner Käfer, der MSP430F149 von Texas Instrumens, ist ein sehr
moderner uC nach der von Neumann-Architektur. Vor allem der Umstand,
dass er ortogonal aufgebaut ist, hat mir den Einstieg sehr erleichtert.
Ortogonal heisst, dass alle Peripheriegeräte, das Ram, Boot-,
Informations- und Hauptspeicher sowie die Interrupt-Vektortabelle in
einen einzigen Speicherbereich abgebildet werden. Das macht die
Programmierung genial einfach und ist einfach genial:

Interrupt-Konfiguration (SFR): 0000h - 000Fh
8Bit-Peripherie:               0010h - 00FFh
16Bit-Peripherie:              0100h - 01FFh

RAM:                           0200h - 09FFh (2KB)

Boot-Memory:                   0C00h - 0FFFh (1KB)
Info-Memory:                   1000h - 10FFh (256B)
Main-Memory:                   1100h - FFFFh

Der ganze Speicher ist ein Flash-Speicher. Programmiert wird dieser von
unten nach oben, wenn ich mich nicht täusche. Bei meinem Datenlogger
habe ich mit dem Debugger die End-Adresse des Programms ausfindig
gemacht und diese als End-Adresse für den Datenspeicher genommen, der
von oben nach unten beschrieben wird. Funktioniert prima, nur wenn man
die Adressen nicht richtig wählt kann man auch das Programm selbst
überschreiben. Dann geht natürlich gar nichts mehr.

Den Vorteil der Von Neumann-Architektur hast du erfasst - zumindest für
Mikrocontroller. Bei ausgewachsenen Rechnern wird dies aber des öffteren
zu einem ernsthaften Sicherheitsrisiko - Stichwort Bufferoverflow.

Der Vorteil der Harvard-Architektur liegt vor allem in der höheren
Geschwindigkeit. Bei uCs ist diese wohl aber eher von kleinerer
Bedeutung, bzw. man kriegt auch Von Neumann-uCs mit derselben Leistung
(vermute ich jetzt mal).

Tom

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Buffer Overflow ist mir noch nicht so ganz klar, vielleicht
kann da mal jemand näheres zu sagen warum das ein Nachteil der
Neumann-Architektur ist?

Wenn man vor dem Beschreiben der Buffer prüfen würde, ob das Datenpaket
auch reinpasst, dann wäre das Problem ja gelöst. Damit könnte man
theoretisch derartige Würmer stoppen. Ich verstehe einfach nicht warum
dennoch soviele Würmer derartige Sicherheitslücken ausnutzen können;
das müsste doch einfach zu stoppen sein!

Im Prinzip liegt doch hier das Problem bei der schlechten/schlampigen
Programmierung (die eben mögliche Fehler nicht abfängt), und nicht bei
der Architektur!

Autor: Gehard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Wahl des uC kann Dir die Architektur egal sein. Dich interssiert
nur wieviele MIPS der uC macht. Wie der das hinkriegt ist sein Problem.

Gerhard

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bufferoverflows an sich werden durch die Harvard-Architektur auch gar
nicht vermieden, es ist nur nicht möglich, auf diesem Wege ausführbaren
Code zu injizieren. Die vom Programm verwendeten Daten können auch auf
einer Harvard-Maschine durch einen Bufferoverflow zerstört werden - was
durchaus unappetitliche Folgen haben kann.

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Bei der Wahl des uC kann Dir die Architektur egal sein. Dich
interssiert nur wieviele MIPS der uC macht. Wie der das hinkriegt ist
sein Problem."

Blödsinn. Ein Mips auf einem 8051 bedeutet wesentlich mehr Performance
als ein Mips auf einem AVR.
Die Mips-Betrachtung krankt an der fehlenden Betrachtung des
Befehlssatzes. Insbesondere wenn man Risc und Cisc hat, ist Cisc
natürlich bei gleichen Mips-Zahlen wesentlich überlegen, eben aufgrund
des komplexen Befehlssatzes, wo einzelne Befehle in Risc durch viele
nachgebildet werden muessen.
Dazu kommt dann noch die bei Risc typische Load- and Store-Architektur,
welche insbesondere im embedded-Bereich bei Mikrocontrollern nochmals
Performance kostet.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Blödsinn. Ein Mips auf einem 8051 bedeutet wesentlich mehr
Performance als ein Mips auf einem AVR."

So simpel ist das nicht. i51 ist akku-orientiert. In Assembler mag das
so stimmen. Aber C arbeitet gezwungenermassen (ANSI Vorschrift) in
vielen Fällen mit 16bit Operation, auch wenn im Quelltext nur Bytes
vorkommen. Und da sieht's bei einem 8-Bit Akku recht mau aus.
Ausserdem ist manches, was in C häufig ist, beim i51 auch etwas
umständlich realisiert.

Freilich: nicht jeder i51 Compiler hält sich an ANSI. CC5X
beispielsweise nicht. So kann man es natürlich auch machen.

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"So simpel ist das nicht. i51 ist akku-orientiert. In Assembler mag
das
so stimmen. Aber C arbeitet gezwungenermassen (ANSI Vorschrift) in
vielen Fällen mit 16bit Operation, auch wenn im Quelltext nur Bytes
vorkommen. Und da sieht's bei einem 8-Bit Akku recht mau aus."


Doch, das ist so simpel.
Zum einen haben gute C-Compiler Optimizer, die unnütze Null-Vergleiche
von den oberen 16-Bit-Hälften wegoptimieren, zum anderen kann man bei
schlechteren Compilern durch Typecasts so etwas von vorneherein
verhindern.


"Ausserdem ist manches, was in C häufig ist, beim i51 auch etwas
umständlich realisiert."

Ich wage mal zu behaupten, dass im Durchschnitt die
Keil-C-8051-Compilate bei gleich-Mips-starken CPUs schneller mehr
Performance haben als die AVR-Varianten.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann zeig mir mal, was bei
   unsigned char a, b;
   if (a > b+1)
        ...
in ANSI-C rauskommt. Bzw. wie der Code aussehen muss, damit das
rauskommt, was Du dir davon erhoffst.

Kannst auch das Beispiel vom Keil selbst nehmen.
http://www.keil.com/support/man/docs/c51/c51_intpromote.htm. Der Code
in Zeile 9 bringt's bei AVR/GCC auf 7 Befehle, bei Keil i51 auf 17.
Die "optimierte" Variante von Keil scheitert bei c2 >= 252.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Zum einen haben gute C-Compiler Optimizer, die unnütze Null-Vergleiche
von den oberen 16-Bit-Hälften wegoptimieren"

Aber den komplett überflüssigen Code im o.A. Beispiel in Zeile 6, den
lässt Keil drin. GCC nicht.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

"Blödsinn. Ein Mips auf einem 8051 bedeutet wesentlich mehr
Performance
als ein Mips auf einem AVR."

Blödsinn.

SCNR :-)

Es kommt, wie immer, drauf an. Bei irgendwelchen Operationen auf Ports
mag das stimmen da der AVR da z.T. den Port-Wert erst in ein Register
Laden muß um darauf eine Operation auszuführen zu können. Der AVR hat
dann aber bei Berechnungen einen Vorteil. Insbesondere wenn die Zahlen
länger als 8 Bit werden oder sogar Fixpunktarithmetik verlangt ist. Es
kommt auf die Anwendung an.
Und oftmals wartet so ein µC eh auf Eingaben von außen und läuft ewig
durch den Mainloop ohne das was passiert. Ich erschlage typische
Regelanwendungen üblicherweise mit einem 4MHz AVR. Weniger ginge
meistens auch aber die 4MHz haben sich halt so eingebürgert.

BTW:
Ich hatte schonmal geschrieben:

MIPS == Meaningles Information about Processor Speed

Matthias

Autor: Stefan Glaser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also: WOW, danke für die vielen kompetenten antworten die schonmal viele
meiner fragen beantwortet haben =)

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias:
War das nicht "Marketing Inspired Processor Speed" ? ;)

Ähnlich wie bei diesem sinnlosen GHz zahlen die man so bei den PCs
sieht.

Wenn man CPUs vergleichen möchte muß man sich mit den interna
beschäftigen und wenn ich mich an mein nebenfach richtig erinnere war
das ein semester grundlagen... (Hennessey & Patternson)

Und die antwort ist dann, niemals einen P4...
Aber das ist (noch) und hoffentlich NIE ein µC.

@Jim:
Wenn ein 8051 und ein AVR jeweils 1 MIPS (gelesen als millionen
instructionen pro secunde) machen, dann ist die performance des einen
nich unbedingt 'besser' als vom anderen, port zugriffe oder nicht.
(mal abgesehen von dem fakt daß die meisten 8051 12x höher getakted
sind als der zum vergleich betrachte AVR).

Ich bin kein experte für (und auch kein freund) des 8051, aber die
meisten befehle benötigen auch noch mehrere maschinen zyklen.
Kann man diese befehle nicht auch mit mehreren RISC befehlen mit
gleicher laufzeitzeit nachbilden?
Nicht immer seh ich ein (BCD-arithmetic) aber dies ist in anbetracht
der zeitkritischen bereiche (i.a.) auch nicht notwendig.

Die load/store architectur ist gerade bei von Neuman architecturen
interessant, denn die verhindert gerade (in der theorie) übermäßiges
laden und speichern von daten von/zum hauptspeicher.

I.a. ist das gesamte hickhack um Havard/von Neumann bei µCs eh egal, da
man sich mit "festen" programmen beschäftigt.

Sollte man aber sowas wie laden von programmen benötigen (von
CF/SD/ATA...) dann haben von Neumann µC gewonnen, da bei allen (?)
Havard µC der programm-speicher flash ist...
Dann nehm ich eher (da GCC verfügbar) ein ARM derivat, als mich mit
8051 (akku,ram-banking,... unbekannter C-compiler) rumzuschlagen.

Olaf

Autor: Tom II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Also noch mal zurück zum eigentlichen Thema:
Dass bei der Programmierung kein Unterschied besteht stimmt ja wohl
nicht wirklich. Wenn ich getrennte Adressbereiche für Code und Daten
habe, dann muss ich verschiedene Befehle verwenden um ein Byte aus dem
Speicher zu laden. So kann z.B. ein printf mit einem String aus dem RAM
funktionieren, mit einem String aus dem Flash aber nicht (vorausgesetzt
der Compiler berücksichtigt das nicht, aber effektiv braucht man dann 2
printf-Funktionen, eine fürs RAM und eine fürs Flash).
Der grosse Unterschied für den Anwender (den ich hier mal mit
Programmierer gleichsetze) besteht in der Zahl der verwendenten
Adressräume. Hat man mehrere Busse, so sind das meistens auch mehrere
Adressräume und Adressen können doppelt vergeben sein.
Also z.B.:
Harvard
Code-Raum:   0x0-0x1fff Flash
Daten-Raum:  0x0-0xff   RAM

Dagegen bei v. Neumann:
0x0-   0x1fff Flash
0x2000-0x20ff RAM

Daher kommt dir oben angesprochene Notwendigkeit für verschiedene
Befehle bei Harvard (je nachdem woher gelesen werden soll).

Zur Performance: Bei denn schnellen, "grossen" uCs mit x-Stufigen
Pipelines macht das wohl keinen grossen Unterschied wie die Architektur
ist, bei 1MHz Controllern ist es sehr wohl ein Kriterium ob ein Befehl
in einem oder zwei Zyklen ausgeführt werden kann.

gruss
Tom

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der zugriff auf unterschiedlichen addressräumen ist schon wichtig zu
wissen, man muß sich halt nur darüber im klaren sein die entsprechenden
funktionen zu benutzen. Und daher ist das insgesammt egal, nicht aber
egal wie. Tschuldige fürs missverständnis.

Gerade bei mehrstufigen pipeline µCs IST ein unabhängiger programm und
daten speicher wichtig, da die unterschiedlichen pipeline stages ja
gleichzeitig speicher bereiche lesen können. Daher auch die
unabhängigen Instruktionen und Daten caches, um eine Havard
architecture nahe zu kommen.

Olaf

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wenn ein 8051 und ein AVR jeweils 1 MIPS (gelesen als millionen
instructionen pro secunde) machen, dann ist die performance des einen
nich unbedingt 'besser' als vom anderen, port zugriffe oder nicht.
(mal abgesehen von dem fakt daß die meisten 8051 12x höher getakted
sind als der zum vergleich betrachte AVR)."

Doch, das ist es schon.
Alleine das Portbitmodifizieren braucht beim AVR drei Befehle gegenüber
einem beim 8051.
Im Übrigen sind eben nicht die meisten 8051er 12x höher getaktet. Schau
Dir mal die Verkaufszahlen an.
Ist aber auch egal, hier ging es um den Mipsvergleich.


"Ich bin kein experte für (und auch kein freund) des 8051, aber die
meisten befehle benötigen auch noch mehrere maschinen zyklen.
Kann man diese befehle nicht auch mit mehreren RISC befehlen mit
gleicher laufzeitzeit nachbilden?"

Beim AVR brauchen die meisten Befehle auch mehrere Zyklen.
Moderne 8051er haben auch eine Pipeline, die so etwas teilweise
ausgleicht.


"I.a. ist das gesamte hickhack um Havard/von Neumann bei µCs eh egal,
da man sich mit "festen" programmen beschäftigt."

Häh?


"Sollte man aber sowas wie laden von programmen benötigen (von
CF/SD/ATA...) dann haben von Neumann µC gewonnen, da bei allen (?)
Havard µC der programm-speicher flash ist...
Dann nehm ich eher (da GCC verfügbar) ein ARM derivat, als mich mit
8051 (akku,ram-banking,... unbekannter C-compiler) rumzuschlagen."


Nochmals häh?

Autor: Einer der Bernds (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Beim AVR brauchen die meisten Befehle auch mehrere Zyklen.

?

Dann habe ich da aber etwas komplett falsch verstanden...

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genaugenommen sind es zwischen 1 und 4 Zyklen, aber schau ins
Datenblatt.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jürgen:
1. 1 maschienen zyklus sind 12 takt zyklen bei den meisten 8051. Es
gibt  auch 8051 die 1 maschienen zyklus mit einem takt zyklus gleich
haben.
Eingesehen.

2. die pipeline gleicht die execution zeit nicht aus, sie wird duch
multi zyklen befehle angehalten (pipeline stall).
Und die AVR-befehle die mehrere zyklen nutzen sind "selten" da man
die speicher zugriffe ja minimiert durch die "große" anzahl
register.
Beim 8051 muß man sich vorwiegend mit dem Akku rumschlagen, wenn man
die werte bewegen um den akku zu sicher...
Und wo liegen die ports? werden die 'direct' mit
  ORL <addr>,#imm
manipuliert. Gerade mal bei atmel nachgesehn und das benötigt 3
maschienen zyklen.
Und einzelne bits in einem port zu änderen ist bei AVR AUCH ein takt.
sbi/cbi
Also ich sehe keinen vorteil der alten architektur.

3. Man programiert den µC und das program ändered sich während des
laufes nicht. Also egal ob von Neumann oder Havard.

4. Nun wie arbeites du an deinem computer? Programme werden während des
laufenden betriebes von externen medien in den RAM geladen und
ausgeführt. Nicht sehr verbreitet bei µCs.

Olaf

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jürgen,

Deine Aussage bezgl. der benötigten Taktzyklen für Instzruktionen bei
der AVR-Architektur ist haltlos : Ein einfacher Blick in das
Instruction Set Summary zeigt, dass tatsächlich ide Mehrheit der
Befehle single cycle instructions sind.
Was natürlich nicht viel  heißen muss, da die Auftretenshäufigkeit
eines speziellen Befehls abhängig vom Porgramm (und auch vom
verwendeten Compiler ist).
Ein Bitschubbserles-Programm benötigt natürlich ganz andere
Instruktionen, als eine Benutzer-Menü-Führung.
Außerdem hat die Anzahl der benötigten Prozessor- oder auch Taktzyklen
nicht viel zu tun mit dem topic, oder was meinst Du ?

MfG, Daniel.

Beitrag #3670092 wurde von einem Moderator gelöscht.
Beitrag #3670098 wurde von einem Moderator gelöscht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.