STK 500 mit bestücktem Speicherbaustein

horst5104

Neues Mitglied
14. Mai 2014
5
0
0
77
Sprachen
Hallo, liebe Forumsmitglieder.
Wer von Euch hat ein älteres STK 500 mit dem bestückten Speicherbaustein und kann mir erklären, wie man diesen verwendet. Mit der englischen Gebrauchsanweisung kann ich nicht viel anfangen, da ist nur die Schnittstelle beschrieben worden. Zur Information - ich bin Anfänger!

Horst5104
 
AFAIK ist der FLASH-IC obsolet bzw nicht mehr verfügbar (seit über 10 Jahren oder so), auf meinem STK ist der nicht bestückt.
Möglicherweise ist das das Datnblatt des ICs.

Ich schaue nachher mal in den Schaltplan des STKs, ich vermute aber, daß der IC (bzw die Pads) mit dem Dataflash-Connector (neben den LEDs) verbunden ist. Von dort kannst Du dann mut Jumperwires auf die SPI-Schnittstelle des AVR verbinden (siehe Userguide des STK S. 3.6)

Das nötige "Kommunikationsprotokoll" sollte sich dem Datenblatt des Flash-ICs entnehmen lassen...

P.S.: Hmm... schonmal wer (von den Besitzern eines unbestückten STK) überlegt, da selbst irgendwas anderes sinniges zu bestücken?
Nachtrag:
So, der Flash ist über 'ne Pegelanpassung (?? - Vcc (5V)<-> Vtg) auf den besagten Dataflash-Anschluß und entsprechende Kontakte des Aux-Headers gelegt. Und zwar nur die 4 SPI-Leitungen. /WP und /BUSY sind mit 47K fest auf Vcc gezogen. /RESET liegt auf dem Master-Reset-Netz des STK.
 
AFAIK ist der FLASH-IC obsolet bzw nicht mehr verfügbar (seit über 10 Jahren oder so), auf meinem STK ist der nicht bestückt.
Möglicherweise ist das das Datnblatt des ICs.

Ich schaue nachher mal in den Schaltplan des STKs, ich vermute aber, daß der IC (bzw die Pads) mit dem Dataflash-Connector (neben den LEDs) verbunden ist. Von dort kannst Du dann mut Jumperwires auf die SPI-Schnittstelle des AVR verbinden (siehe Userguide des STK S. 3.6)

Das nötige "Kommunikationsprotokoll" sollte sich dem Datenblatt des Flash-ICs entnehmen lassen...

P.S.: Hmm... schonmal wer (von den Besitzern eines unbestückten STK) überlegt, da selbst irgendwas anderes sinniges zu bestücken?
Nachtrag:
So, der Flash ist über 'ne Pegelanpassung (?? - Vcc (5V)<-> Vtg) auf den besagten Dataflash-Anschluß und entsprechende Kontakte des Aux-Headers gelegt. Und zwar nur die 4 SPI-Leitungen. /WP und /BUSY sind mit 47K fest auf Vcc gezogen. /RESET liegt auf dem Master-Reset-Netz des STK.

Danke für den Antwort, LotadaC.
Eigentlich wollte ich nur wissen, wie man den Speicherbaustein im laufenden Betrieb nutzen kann. Kann man softwaremäßig darauf zugreifen, um bestimmte Daten abzuspeichern und wieder auszulesen? Das kann nur jemand wissen, der mit der alten Ausführung des STK 500 gearbeitet und dieses Feature auch benutzt hat. Aber da scheint es wohl niemanden mehr zu geben.

horst5104
 
Wie gesagt liegt der Kommunikationstechnisch am Dataflash-Header an. Von dort kannst Du ihn auf irgendwelche SPI-Beine (Portx-Header) weiter verbinden. Ob nun Hard- oder Software, ist Deine Sache. Welches Kommunikationsprotokoll zu verwenden ist, ist dem DB des Speicherbausteins zu entnehmen.

Bin mir jetzt nicht sicher, ob der Master-Controller nicht auch Zugriff hat...
 
...Bin mir jetzt nicht sicher, ob der Master-Controller nicht auch Zugriff hat...
Ja, der Master-Controller ( Ist bei Dir vielleicht ein AT90S8535?, bei mir ein ATmega8535L) ist über A0..A3 mit dem Flash(-sockel) verbunden - prinzipiell ist der also in der Lage, den zu nutzen. Inwiefern der firmwaretechnisch entsprechend programmiert ist, und ob das in irgendeiner Version des AVR-Studios direkt über den Master genutzt wird/wurde, mußt Du selbst recherchieren - technisch möglich ist es zumindest.
Aber wie gesagt, der Target-AVR kann das natürlich auch, wenn Du es programmierst; bedenke jedoch, das der Speicher als FLASH nur begrenzt oft beschreibbar ist (also jede Adresse) -> Datenblatt.
 
Hallo Horst,

  1. gib mal bitte an, ob überhaupt noch Interesse an der ganzen Geschichte besteht.
  2. gib mal bitte die genaue Bezeichnung des, auf Deinem STK bestückten Flash-IC an (die Page-Längen basieren scheinbar nicht auf Zweierpotenzen - ab Revision D scheint der aber einmalig(!) auf 'ne Zweierpotenz umkonfiguriert werden zu können)
  3. nur interessehalber: welcher Master-Controller ist auf Deinem Board?
  4. Welche Programmierumgebung, welche Sprache, welchen Target-Controller willst Du nutzen?

P.S.: wehe, ich hab mich hier umsonst in die Datenblätter reingekniet...:hmmmm:

P.P.S.: Ab Produktionsdatum Oktober 2002 scheinen die nicht mehr bestückt zu sein...
 
Hallo Horst,

  1. gib mal bitte an, ob überhaupt noch Interesse an der ganzen Geschichte besteht.
  2. gib mal bitte die genaue Bezeichnung des, auf Deinem STK bestückten Flash-IC an (die Page-Längen basieren scheinbar nicht auf Zweierpotenzen - ab Revision D scheint der aber einmalig(!) auf 'ne Zweierpotenz umkonfiguriert werden zu können)
  3. nur interessehalber: welcher Master-Controller ist auf Deinem Board?
  4. Welche Programmierumgebung, welche Sprache, welchen Target-Controller willst Du nutzen?

P.S.: wehe, ich hab mich hier umsonst in die Datenblätter reingekniet...:hmmmm:

P.P.S.: Ab Produktionsdatum Oktober 2002 scheinen die nicht mehr bestückt zu sein...

Danke für deine Erklärung, LotadaC!
Natürlich besteht noch Interesse. Ich bin Anfänger und unheimlich neugierig, wie alles funktioniert. Habe schon mit dem Arduino gearbeitet und dann den Wunsch entwickelt, selbständige Controller zu brennen. So kam ich dann per EBAY preiswert an das STK 500, ohne bestücktem Flash-Speicher. Aber als Funkamateur mit einem riesigen Teile-Lager habe ich in der Schublade einen Chip mit der Bezeichnung "Atmel, AT45DO21 - R1 /0001" gefunden, und würde diesen gern nachbestücken, wenn ich ihn nutzen könnte. Der Prozessor ist ein "Atmega 8535 L /8AU/0629". Mein Betriebssystem ist Windows 8.1, was nur mit neueren Programmen zusammen spielt. Der Verkäufer hat mir Atmel Studio 6.1/Sp2 mitgeliefert, was mit dem neuen Windows funktionieren soll. Literaturmäßig habe ich mich auf Arduino und Bascom-Basis eingedeckt. Als Target-Controller habe ich zum Lernen den Atmega 8 und den Attiny 13 eingekauft, die auch in meinen Lehrbüchern verwendet werden. Atmel hat in der Betriebsanleitung des STK 500 wohl erklärt, wie die Schnittstelle für den Flash-Speicher verbunden wird, aber mit keinem Wort erwähnt, wie der Speicher anzusprechen ist (bei Windows wäre es eben ein Laufwerk). Auf der Google-Suche nach einer Erklärung bin ich aber nur auf die gleiche Frage, die auch andere hatten, gestoßen, die aber von Niemanden beantwortet wurde. Aber ich habe noch nicht aufgegeben, das Geheimnis des Flash-Speichers zu lösen. Vielleicht hilft du mir dabei?

horst 5104
 
Bezüglich BASCOM wirst Du hier potentere Köpfe finden (Cassio zB) - ich kann Dich aber gern versuchen(!) in der Hardware zu unterstützten (!). Wenn ich Zeit finde...

Arbeite Dich mal in das (vollständige) Mega8-Datenblatt und das des Flash-ICs ein. Insbesondere die SPI-Schnittstelle.

P.S.: hast Du noch mehr von den Dingern in der Schublade?;)
 
Hallo Horst,

Auf der Google-Suche nach einer Erklärung bin ich aber nur auf die gleiche Frage, die auch andere hatten, gestoßen, die aber von Niemanden beantwortet wurde. Aber ich habe noch nicht aufgegeben, das Geheimnis des Flash-Speichers zu lösen. Vielleicht hilft du mir dabei?

der Flash-Speicher wird wohl ähnlich einem EEPROM angesprochen (vermute ich jetzt mal). Müßte ich jetzt aber erstmal im Datenblatt nachsehen. Es wird auf jeden Fall nicht sowas wie ein Laufwerk sein. Du wirst eher auf Byte-Ebene Daten hinschicken und zurückbekommen. Du wirst den Adresszähler im Flash selber setzen müssen. Es wird wohl auch Kommandos für das Löschen von Bereichen oder dem gesamten Baustein geben.

Das Datenblatt: Anhang anzeigen AT45D021A_2MBit-Dataflash.pdf

Gruß
Dino
 
Naja... es geht schon über Sektoren, Pages usw, außerdem kann der Zugriff über integrierten SRAM laufen. (Und dann die ganze page umschaufeln lassen. Hier die Besonderheit, daß die Dinger nicht zwingend auf Zweierpotenzen laufen (deswegen die Frage nach der Revisionsnummer))

Ich finde den Vergleich zum Laufwerk gar nicht so falsch - man muß halt den Treiber selbst programmieren...
 
So, mal ein paar Fakten (aus dem Datenblatt des Flash-ICs):

generelles zu Architektur:
Der IC beinhaltet 270336 Bytes Flash-Speicher, welche in 128 Blöcken mit je 8 Pages mit je 264 Bytes "angeordnet" sind (ja, 256+8 Bytes je Page). Zur Adressierung einer Page wird also ein 7bit(Block)+3bit(Page im Block)=10bit-breiter Adress-Pointer benötigt; um ein Byte in einer Page zu adressieren nochmal ein 9bit-breiter.
Außerdem 2 Pages mit je 264 Bytes SRAM-Speicher. Werden auch als Buffer bezeichnet, der Flash wird Page-weise darüber beschrieben. Für die Adressierung eines Bytes in Buffer1/2 wird logischerweise auch ein 9bit-breiter Adresspointer benötigt.
Dann gibt es noch ein auslesbares Statusregister, welches anzeigt, wenn der IC mit einer Schreib-/Transferoperation "ausgelastet" ist, und das Compare-Ergebnis bereitstellt.
  • An einen AVR anbinden solltest Du den mit SPI-Mode 0 oder 3 können - Mode 3 ist default (kann aber umgeschaltet werden) - was die anderen beiden Modi sind (inactive clock high/low) ist mir nicht ganz klar (bzw der Unterschied zu den SPI-Modi) - Dino??
  • Die maximale SCK-Frequenz beträgt 15MHz für Operationen innerhalb einer Page (Erklärung später), wird eine page-Grenze überschritten, muß dort "gewartet" werden -> mit generell max 10MHz kommt man " problemlos über die Grenzen"
  • Der Flash wird immer Page-weise beschrieben (immer eine ganze Page).
  • Vor dem bescheiben ist die Page zu löschen (Anmerkung: dabei wird alles zu "1", Frage an Dino: wenn man nicht löschen würde, und irgendwo 'ne 0 steht welche (ohne löschen) mit einer "1" beschrieben werden würde, würde die jetzt "0" bleiben, oder wie?)
  • Außerdem müssen die Flash-Pages ab und zu "refresht" werden, wann ist mir nicht so recht klar. Scheinbar werden alle gespeicherten Bytes in Pages bei jeder Schreiboperation (anderer Pages) "mitangegriffen", alle 10000 page-writes sollten alle pages refresht werden ... denk ich mal
    Dino, bitte ggf korrigieren

Folgende Operationen kannst Du veranlassen/ausführen:
  • Contiuous Array Read - es wird ein Startbyte in einer Page in einem Block des gesamten Flash adressiert (also 19 bit), und mit ein paar Dummy-Bits gesendet, danach wird beginnend ab dem adressierten Byte mit jedem SPI-Transfer ein Byte vom Flash (Slave) zum AVR (Master) über MISO ... ähm ... transferiert. Der Pointer im Flash inkrementiert dabei, durchläuft so den gesamten Flash und ggf von 270335 auf 0 über. Der Burst Array Read ist strenggenommen dasselbe, nur eben mit einer einzuhaltenden Verzögerung bei einem Page-Umbruch bei Sck-Frequenzen über 10MHz
  • Main Memory Page Read - analog zum Continuous Array Read, allerdings wird nur die adressierte Page ausgelesen, der Pointer läuft innerhalb der adressierten Page über.
  • Statusregister Read - Es wird das Statusregister ausgelesen. Das MSB ist das Ready/!Busy-Flag, welches 0 ist, wenn der IC intern das Flash beschreibt/löscht. solange darf nicht auf den Flash-Bereich zugegriffen werden, aber auf den ungenutzten Buffer und das Statusregister. Das Flag wird in Echtzeit aktualisiert - wenn nach dem Opcode ein Clock-Impuls folgt, liegt das Flag direkt auf der MISO-Leitung, und kann dort vom AVR "beobachtet" werden.
    Bit6 nimmt das Ergebnis eines Page to Buffer-Compares auf, und kann so ausgelesen. Bit5..3 enthält die device-density (??), und sollte 010 sein.
  • Buffer 1/2 Read - nach dem Opcode wird (außer Dummy-Bits) noch eine Startadresse (klar, mit 9bit) im Buffer1/2 (also im SRAM) übertragen, danach können nacheinander beliebig viele Bytes aus dem Buffer ausgelesen werden (MISO). Der Pointer beginnt also mit der übertragenen Adresse, inkrementiert nach jedem Byte und läuft ggf innerhalb des Buffers über (bzw beginnt von vorn).
  • Buffer 1/2 Write - ähnlich zum Buffer read, nur daß hier eben Bytes über die MOSI-Leitung in den Buffer übertragen werden. Auch hier wieder beliebig viele, wobei der Pointer ggf innerhalb des Buffers überläuft
  • Buffer 1/2 To Main Memory Page Program With Erase - es wird die Ziel-Page adressiert (mit 10bit - also 7bit(block)+3bit(page) - und ein paar Dummybits). Nach der steigenden Flanke von CS beginnt der Chip mit dem löschen der Page, und überträgt anschließend den Bufferinhalt in die Page. Solange ist das RDY-Flag 0. Auf den verwendeten Buffer und den Flash sollte man also solange nicht zugreifen.
  • Buffer 1/2 To Main Memory Page Program Without Erase - dasselbe, ohne automatischem Löschen der Page.
  • Page Erase - damit wird eine adressierte (10bit) Page (im Flash) gelöscht. (Nach der steigenden CS-Flanke gehts los, RDY-Flag solange =0)
  • Block Erase - löscht analog dazu gleich einen ganzen Block (8 Pages), welcher logischerweise nur mit 7bit adressiert wird.
  • Main Memory Page Program Through Buffer 1/2
  • Main Memory Page To Buffer 1/2 Transfer
  • Main Memory Page To Buffer 1/2 Compare
  • Auto Page Rewrite Through Buffer 1/2

Wird noch ergänzt
 
Bezüglich BASCOM wirst Du hier potentere Köpfe finden (Cassio zB) - ich kann Dich aber gern versuchen(!) in der Hardware zu unterstützten (!). Wenn ich Zeit finde...

Arbeite Dich mal in das (vollständige) Mega8-Datenblatt und das des Flash-ICs ein. Insbesondere die SPI-Schnittstelle.

P.S.: hast Du noch mehr von den Dingern in der Schublade?;)

Leider nein, LotadaC.
Wenn ich es nicht gehabt hätte, hätte ich es bei "bbshonic" über Ebay gekauft (7,99 USDL).

Vielen Dank für Deine Mühe. Inzwischen habe ich mich weitergebildet. Auch der Arduino lässt sich mit einem Flash-Speicher erweitern, wofür man zur Verwaltung der Speicheradressen eine Bibliothek braucht. Da der Flash -Speicher beim STK 500 an den Main-Prozessor angebunden ist, gehe ich davon aus, daß der auch die entsprechende Bibliothek enthält. Dann müsste sich der Speicher über die Software bedienen lassen. Das werde ich herausfinden, wenn ich das AVR-Studio 6 installiert habe. Es gab da noch ein Problem mit meinem neuen Rechner, daß die auf meinen besonderen Wunsch vom Händler eingebaute RS 232 Schnittstelle nicht vorhanden war. Nach dem Studium des ASUS Motherboard-Handbuchs musste ich feststellen, daß die Schnittstelle im BIOS abgeschaltet war. So taste ich mich langsam, aber immer weiter vorwärts.

Gruß horst 5104
 
Hmm... zum Arduino kann ich generell nicht viel sagen - sofern mir bekannt, verwenden die irgendso'ne C-ähnliche Programmiersprache, oder?

Zur Sache mit den Bibliotheken: Die müssen entweder auf einen bestimmten Chip zugeschnitten sein, oder aber für viele, wobei Du irgendwo konfigurieren mußt, welchen Du jetzt einsetzt. Wenn das alles nicht ordentlich dokumentiert ist...

Ich würde mir bei sowas die benötigten Routinen für den konkreten verwendeten Chip lieber selbst schreiben, dann weiß ich nnämlich genau, was die machen. Klar, wenn ich dann mal'n anderen Chip verwenden will, muß ich das wieder anpassen.
Dafür bekommt der AVR dann auch nur die nötigen Routinen mit.

Wo liegt der Verwendungszweck des Speichers: Prinzipbedingt sollten die Daten ja nicht oft überschrieben werden - also eher ein statischer Speicher. Zeichensätze für (graphische) Displays, (Hintergrund-)Bilder, irgendwelche "Audiosignale" usw. Die AVR besitzen ja selber einen Program Flash, in dem man solche Sachen grundsätzlich auch unterbringen kann (und leichter/schneller auslesen) - allerdings nicht so viel.
Oder zur Langzeit-Aufzeichnung irgendwelcher ermittelten (gemessenen) Daten.

Achso, habe mal ein wenig bei Reichelt geschaut - inzwischen gibt es ähnliche Bausteine, mit mehr Möglichkeiten (zB werden die, hier im DB angedeuteten Sektoren genutzt (Sektor erase, chip erase), außerdem können einzelne Sektoren per Software schreibgeschützt werden usw. Habe die Opcodes jetzt nicht verglichen, vieles scheint auf den ersten Blick ähnlich zu sein. Allerdings ist die geringere Versorgungsspannung zu beachten (und damit auch die kleineren Logikpegel).
Zu der Sache mit der echten RS232-Schnittstelle am PC: ich verwende inzwischen den Onboard-Programmer des STK gar nicht mehr. Der wird ja letztlich über den ISP6-Header mittels Pfostenkabel auf den SPROG-Header des entsprechenden Sockels verbunden. Ich verwende stattdessen einen AVRISP MKII, den ich statt des STK-Programmers mit SPROG verbinde (dann müssen ein paar nur ein Jumper auf dem STK geöffnet werden) . Der AVRISP MKII läuft über USB. Ebenso kannst Du auf den seriellen Onboard-RS232-TTL-Pegelwandler (Spare) verzichten, und einen seriellen TTL-USB-Wandler nutzen.
Strenggenommen kannst Du dann allerdings auch ganz auf das STK verzichten, und den AVR auf'n Breadboard stecken, aber Stromversorgung, LEDs, Taster usw des STK sind halt "fertig".
Die vom STK generierte Vtg, Aref kannst Du natürlich nur über die RS232-Schnittstelle des STK (und das Studio?) einstellen, ich habe noch nicht versucht, einen USB-RS232 wandler zu verwenden - sollte aber eigentlich klappen.
Außerdem kann der STK-Programmer das Target auch High-Voltage-Programmieren - das kann der AVRISP nicht.
(Und für Thomas B.: ja, der Drachen kann das auch, dafür kann der kein TPI:p)
 
Naja... es geht schon über Sektoren, Pages usw, außerdem kann der Zugriff über integrierten SRAM laufen. (Und dann die ganze page umschaufeln lassen. Hier die Besonderheit, daß die Dinger nicht zwingend auf Zweierpotenzen laufen (deswegen die Frage nach der Revisionsnummer))

Ich finde den Vergleich zum Laufwerk gar nicht so falsch - man muß halt den Treiber selbst programmieren...

Danke für Euren umfangreichen Einsatz in dieser Frage, LotadaC und Dino.
Es wird noch einige Zeit vergehen, bis ich als Anfänger diese Hürde nehmen kann. Wenn sich der Speicherbaustein nicht über das Steuerprogramm AVR-Studio händeln lässt, lohnt es für mich zunächst nicht, ihn auf die Platine zu löten. Vielleicht finde ich ja noch jemanden, der mit dem alten STK 500 Erfahrung gesammelt hat, die er an mich weitergeben kann. Euch erst einmal noch vielen Dank!

horst5104
 
Hmm... irgendwie hatte ich wohl scheinbar vergessen, den geänderten Beitrag zu speichern... jetzt isser gesperrt; also nochmal kurz:
Main Memory Page Program Through Buffer 1/2
Hier wird eine Startadresse im Buffer und eine Page im Flash adressiert, danach werden beliebig viele Bytes in den Buffer geschrieben. Nach der steigenden CS-Flanke löscht der IC automatisch die entsprechende Page, und kopiert die Daten aus dem Buffer dahin. Auch hier ist das Busy-Flag aktiv.
Main Memory Page To Buffer 1/2 Transfer
Hier wird die adressierte Page in den Buffer kopiert (zB für Compares oder Buffer read, oder um gezielt einige Bytes zu ändern, und das dann zurückzuschreiben).
Main Memory Page To Buffer 1/2 Compare
Die adressierte Page wird mit dem Buffer verglichen - das Ergebnis ist in Bit6 des Statusregisters ablesbar.
Auto Page Rewrite Through Buffer 1/2
Löst ein rewrite der adressierten Page über den Buffer aus. Die Page wird in den Buffer kopiert, anschließend gelöscht, und dann aus dem Buffer wiederhergestellt.
Das sind die Grundfunktionen, die der IC kann (hatte Dino ja zu Beginn angedeutet). Die Opcodes bestehen dann je aus einem konstanten Kommandobyte, und (außer Statusregister lesen) 3 Parameterbytes, die die Adressen aufnehmen (folglich variabel). Ggf kommen hinterher noch Dummy-Bytes. Danach folgen ggf die Datenbytes.
Man könnte also Subroutinen (für jede Aufgabe da oben), irgendwie die Adressen und Daten (als Argument) übergeben bekommt, die Bytes des Opcodes usw berechnet, den CS bedient, und das alles über das SPI schickt - und je nachdem dann eben die Daten mitsendet/empfängt.
MMn ist es ausreichend, die Daten im Flash unter festen Adressen zu speichern - kommt sicher auf die Anwendung an...
Ich würde den erstmal gar nicht auflöten, sondern direkt testen. Ich habe allerdings auch sowas (Dino könnte mit seinen Challengern Erfolg haben). Aber egal, arbeite Dich bei den AVR erstmal in die Grundlagen ein (mit der Sprache Deiner Wahl), beschäftige Dich mit der Hardware der Controller selbst (Datenblätter) - der Tiny13 bringt ja da nur wenig mit (übersichtlicher), der Mega8 hat mehr...

Und wenn Du Fragen hast, frag...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)