Erledigt Fragen zur Eingangsspannung ATtiny

AVR Neuling

Mitglied
31. Juli 2013
38
0
6
Sprachen
Ich möchte einen ATtiny45 an zwei NiMh Akkus betreiben. Die Spannung wird in etwa zwischen 2,0V und 2,5V liegen. So wie ich das Datenblatt verstanden habe, funktioniert dies nur mit der Version ATtiny45V-10. Soweit richtig?

Seine Aufgabe ist es unter anderem, festzustellen, ob an einem Pin eine Spannung anliegt oder nicht. Diese beträgt allerdings 3,3V. Muss ich diese Spannung nun über einen Spannungsteiler an den ATtiny anlegen oder kann ich sie direkt anlegen? Auf Grund dessen, dass sie innerhalb des Bereichs liegt, in dem der ATtiny betrieben werden darf, denke ich, dass es ohne Spannungsteiler funktioniert. Aber so ein Käfer kostet um die 2 Euro und da frage ich lieber nach, bevor ich ihn in die ewigen Jagdgründe schicke.
 
Hi,

die AVRs gehen (fast) alle bis 1,8V runter (manche sogar noch tiefer), sollte also kein Problem sein. Vorsicht aber wenn du bei solch niedrigen Spannungen in den EEPROM schreiben willst. Da gibt es Einschränkungen.

Und wie bei fast allen Bauteilen darf eine Signalspannung nicht größer sein als die Betriebsspannung. Steht auch im Datenblatt. Ist meine ich bei allen bei VCC+0,3V Maximum. Also wirst du um Teiler nicht drum herum kommen, oder um andere Lösungen wie Pegelwandler, R und Z-Diode, ... .
 
Zuletzt bearbeitet:
Hallo,

der Tiny45 kann 2V7..5V5, der Tiny45V 1V8..5V5. (also wie Du vermutet hattest). Der -V kann dann (garantiert) extern bis 10MHz betaktet werden - grundsätzlich kann der 45er ja mittels seiner internen PLL mit intern erzeugten 16MHz laufen, inwiefern das bei der V-Variante dann noch geht... kA.
Abgesehen davon sollte bei niedrigen Spannungen der Takt eh kleiner sein...

Hast Du mal einen Bilck auf meine Übersicht (Ressourcen) geworfen - da erschließt sich das mit den L, V usw-Varianten

Die ganz alten Controller (für den 45er wäre das der 15, zu dem ich aber ohne L nichts gefunden habe) konnten ca 4..5V5, und in 'ner L-Variante dann 2V7..5V5 (mit reduziertem maximalen Takt).

Später kamen dann welche, die grundsätzlich mit 2V7..5V5 liefen, und als V-Variante (mit reduziertem...) mit 1V8..5V5.

Dann kamen A-Versionen, die grundsätzlich mit 1V8..5V5 lauffähig waren, ohne Selektion in L- V-Varianten.
Das gilt auch für alle neueren Controller, die dann teilweise keine Buchstaben hinter der Nummer haben (zB Tiny4313, Tiny441 usw).

Grundsätzlich begrenzt die Spannung den Maximal zulässigen Takt, ausserdem funktionieren (Schreib-)Zugriffe auf den Eeprom erst ab bestimmten Spannungen zuverlässig. AFAIR gilt das auch für das beschreiben des Programm-Flash.

Hervorzuheben ist noch der Tiny43U, der einen integrierten Schaltregler besitzt, und damit ab 0V7 oder so läuft.

An Beinen anliegende Spannungen sollten den Bereich Gnd..Vcc nicht verlassen, allerdings besitzen die Beine Schutzdioden nach Vcc und Gnd - wenn der Strom also begrenzt wird, können diese Spannungen nach Vcc/Gnd abgeleitet werden. Ich meine mal, einen RS232-Empfänger gesehen zu haben, wo auf diesem Wege die +/-12V über den Controller fließen. Das ganze soll funktioniert haben, aber ordentlich ist das nicht...

Also ich würde auch zu einem Teiler raten, der die Spannung sicher auf höchstens 2V runterteilt. Was ist, wenn oben keine 3V3 anliegen, ist der dann offen, oder Gnd. Offen würde für den Controller ja kein auswertbares Signal darstellen, der Teiler würde hier quasi als PullDown für saubere Verhältnisse sorgen...
 
Vielen Dank für die umfangreichen und vor allen Dingen verständlichen Antworten. Ich werde in dem Fall dann einen Spannungsteiler mit 6,8K und 10K nehmen. Die 10K gleichzeitig als PullDown zu nutzen - auf die Idee bin ich noch nicht gekommen. Danke für den Tip!

Wie sieht es denn aus, wenn ich zwei verschiedene (beide 3,3V) µC über je einen I/O miteinander verbinde? Muss da auch ein PullDown bzw. PullUp dran oder kann man die ohne zusätzliche Beschaltung miteinander verbinden?
 
Wie sieht es denn aus, wenn ich zwei verschiedene (beide 3,3V) µC über je einen I/O miteinander verbinde? Muss da auch ein PullDown bzw. PullUp dran oder kann man die ohne zusätzliche Beschaltung miteinander verbinden?

Kommt drauf an wie du die verbindest. I2C/TWI setzt immer PullUps voraus. Es könnte auch ohne gehen, aber das ist dann reine Glückssache. SPI braucht eigentlich keine PullUps, aber ich rate sehr stark an die Select Leitung der Slaves hoch zu ziehen, sonst passiert dir beim Flashen (ISP) möglicherweise sowas wie mir: http://www.makerconnect.de/index.php?threads/spaß-bei-der-arbeit.2852/page-2#post-33030

UART braucht keine PullUp oder -Down, zumindest habe ich noch nie welche verbaut und es läuft 1a :)
Solltest du dir was eigenes stricken wollen (oder dir reichen einzelne Signale statt ein echter bytetechnischer Datenaustausch), der AVR hat interne PullUps die du per Software pro Pin aktivieren kannst wenn er als Eingang definiert ist.
 
Da habe ich mich wohl nicht ganz klar ausgedrückt. Die beiden µC sind nur mit je einem Pin verbunden. Der erste µC gibt darüber einen Zustand eines seiner Eingänge (zu einem bestimmten Zeitpunkt) weiter an den zweiten µC, der teilweise stromlos ist und daher diesen Zustand eventuell "verpasst". Den PullUp über Software zu aktiviere wäre nichts für mich. Ich mache das lieber in Hardware, da kann ich das Aktivieren nicht vergessen oder versehentlich auskommentieren. Es würde also genügen, die beiden Pins zu verbinden und über einen 10K Widerstand auf Masse zu legen?
 
Jupp :)
 
nicht ganz klar ausgedrückt. Die beiden µC sind nur mit je einem Pin verbunden.
Mir wird trotzdem nicht ganz klar, worauf Du hinaus willst...
Die beiden Controller müssen zusätzlich dasselbe Gnd haben (also auch die Gnd-Pins verbunden) - sicherheitshalber nochmal klargestellt
Zustand eines seiner Eingänge (zu einem bestimmten Zeitpunkt) weiter an den zweiten µC, der teilweise stromlos ist und daher diesen Zustand eventuell "verpasst".
Jetzt zu den Beinen:
Wenn ein Pin als Ausgang definiert ist (DDR-Bit gesetzt), wird der Ausgangstreiber des Beines aktiviert, und der Zustand des PORT-Bits auf das Bein geschaltet -> Bein ist entsprechend mit Vcc oder Gnd des Controllers verbunden.
Wenn der Pin Eingang ist (DDR-Bit gelöscht), ist der Treiber inaktiv, das Bein erstmal tristate. Zusätzlich kann ein interner Pullup aktiviert werden (bei den meisten AVR über das PORT-Bit).
Egal ob Ein- oder Ausgang, das Pin-Bit liefert Dir den tatsächlichen digitalen (Hi/Lo) Zustand des Beines. Wenn aber weder ein externer Pegel draufliegt, noch der Controller selbst einen Pegel drauflegt (Ausgang oder Pullup), hängt das Bein komplett in der Luft. Quasi 'ne Antenne. Dann kann jeder beliebige Zustand gelesen werden, insbesondere kann der Pegel ständig hin- und herkippen (wodurch der "digitale Input Buffer" (Schmitt-Trigger und D-Q-Latches) ständig umgeladen werden, was den Stromverbrauch erhöht) - hängt da dann 'n Interrupt dran, triggert der ggf ununterbrochen.
Dein sendender Controller legt aber eigentlich einen logischen Pegel drauf, sofern der Pin Ausgang ist.
Was meinst Du jetzt mit "verpassen"? Wenn der Empfänger gerade aus war als der Sender die Leitung high hatte, und die inzwischen wieder low ist? Da würde Dir eh kein Pull-Widerstand helfen.
Abgesehen davon bekommst Du dabei ein ganz anderes Problem:
Wenn der Sender ein Hi auf die Leitung legt während der Empfänger stromlos ist, aber beide dieselbe Masse (Gnd) haben, ist die Spannung am Empfängerpin grösser als dessen Vcc, folglich wird die Spannung über die interne Schutzdiode auf Vcc abgeleitet, der Empfänger also über das Bein und die Schutzdiode mit Spannung versorgt. Der startet also - ob und wielange die Schutzdiode das mitmacht, kA...

Kannst Du konkretisieren worum es geht? Warum der 2te manchmal stromlos sein muß?
Würde es vielleicht reichen, den schlafen zu schicken (dann kann er auch nicht verpassen/ein Pegelwechsel auf der Leitung ihn aufwecken)?
 
Die ganze Geschichte ist etwas tricky. Es handelt sich um eine batteriebetriebene Schaltung, die nur selten startet und bei der es auf extrem geringen Stromverbrauch an kommt. Ein µC ist im Schlafmodus und wird durch einen Trigger geweckt. Er durchläuft sein Programm nur ein einziges Mal, um nach etwa 10 Sekunden wieder in den Schlafmodus zu gehen. In dieser Zeit gibt er die Stromversorgung für den stromlosen µC frei, liest den Zustand des besagten Einganges aus und setzt einen Ausgang entsprechend auf HIGH oder LOW. Der zweite µC ist also schon an, wenn der Ausgang des ersten µC ein Signal an den zweiten µC "sendet". Zum Schluss kappt er die Stromversorgung zum zweiten µC und legt sich direkt im nächsten Befehl schlafen. Es gibt also praktisch keinen nennenswerten Zeitpunkt, zu dem er ein HIGH sendet, obwohl der zweite µC aus ist. Das alles ist bisher reine Theorie, da ich noch in der Planung bin. Trotzdem danke für die sehr umfangreiche Erläuterung. Das sind für Anfänger wie mich Basics, die man immer mal wieder brauchen wird.
 
Hm. Warum 2 Controller sehe ich jetzt nicht so, aber egal.
Wenn du den Controller schlafen legst so dass er nur noch per INT aufgeweckt werden kann sollte er nur um die 10µA benötigen. Ich könnte mir vorstellen dass solche Geschichten mit PullUp und -Down mehr schlucken könnte. Hängt aber von der Schaltung ab.
Wobei bei dem Scenario du weder noch brauchst, da der sendene AVR einen definitiven Pegel ausgibt.

Was LotadaC sagte, da musst du wirklich drauf aufpassen, das hatte ich ganz übersehen. Wenn der AVR Spannungsfrei ist müssen es die Pins auch sein.

In meinen batteriebetriebenen Schaltungen dulde ich den Stromverbrauch. Oder in größeren Schaltungen nutze ich Schaltwandler um auf 5V runter zu kommen. Die haben ne Enable Leitung. Setz ich die auf 0 is 5V Ausgang weg und somit die gesamte Schaltung aus. Ein Taster zieht die Enable Leitung wieder hoch und der AVR hält ihn oben so lange wie benötigt.
 
Kommt halt auf den Wert des Pull-Widerstandes an...
Der Spannungsteiler für die zu erfassende Spannung belastet auch die Quelle, sollte ggf entsprechend hochohmig gestaltet werden.
Zu der Sache mit den 2 Controllern: das geht sicher so, hatte lediglich erfragen wollen warum er nicht mit einem auskommt, der meist schläft.

Zu Deinen Schaltreglern: die schlafen dann auch, mit einem entsprechendem Minimalverbrauch. Und das gilt mMn nur für Abwärtswandler. Bei Aufwärtswandlern hast Du ja meist Vin -> Pufferkondis -> Induktivität -> Schalter gegen Gnd -> Diode -> Pufferkondis -> Vout
Wenn der Regler (der den Schalter gegen Gnd bedient) disabled wird, geht trotzdem Vin über Spule und Diode nach Gnd.
Da bräuchte man dann einen PNP-Transistor (bzw den entsprechenden FET) vor der Spule.

Aber vielleicht sieht @dino03 das ganz anders...
 
Ich hätte noch eine grundsätzliche Frage zu dem Tiny45V. Laut Datenblatt läut der bei 1,8V nur mit 0-4Mhz. Bisher mache ich es so, dass ich die Tinys (die mit 3V3 bzw. 5V laufen) mit dem Bootloader aus der Arduino IDE versehe, wodurch der interne Takt, wenn ich das richtig in Erinnerung habe, auf 8 Mhz eingestellt wird. Da wird wohl irgend etwas an den Fuses verstellt. Aber so ganz steige ich da nicht durch.

Wie kann ich feststellen, mit welchem internen Takt ein Tiny läuft und was ist die Einstellung, wenn er jungfräulich geliefert wird? Ist das dann 1Mhz?
 
Hallo,

prinzipiell mMn ist es eher so, daß das garantierte Zahlen sind. Die ICs werde aus dem Wafer gesägt, und (wahrscheinlich) getestet. Wenn sie sicher bei 20MHz laufen, werden sie als Tiny ohne V sortiert, wenn sie sicher mit 1,8V laufen als Tiny-V.
Selektion...
Wie Du korrekt abgelesen hast, gibt es für die anliegende/geforderte Taktfrequenz 'ne MindestSpannung - also die Spannung, wo Atmel garantiert, daß der Chip dann mit dieser Frequenz ordentlich läuft.

Aber Achtung: für das sichere beschreiben (teilweise auch das Lesen) des Eeprom gelten manchmal andere Werte.
Und zumindest auch bei manchen Controllern für das beschreiben des Programflash (zB beim ATtiny4/5/9/10).

Genau deswegen werden die Controller mit voreingestelltem langsamen Takt (meist um 1MHz) ausgeliefert - und da die Zielumgebung nicht unbedingt 'ne externe Taktquelle vorsehen muß, mit voreingestelltem internen Takt.

Beim Tiny45V steht im Datenblatt (6.3.2)
By default, the Internal RC Oscillator provides an approximate 8.0 MHz clock. Though voltage and temperature dependent, this clock can be very accurately calibrated by the user. See “Calibrated Internal RC Oscillator Accuracy” on page 169 and “Internal Oscillator Speed” on page 197 for more details. The device is shipped with the CKDIV8 Fuse programmed.
In Table6-6 findest Du ferner, daß der interne 8MHz-Oszillator Standardeinstellung ist (alternativ könnte der ATtiny15-Kompatibilitätsmodus 'n effektiven 1,6MHz einstellen, aber default schwingts erstmal(!!) mit 8MHz).
Diese 8MHz liegen am System Clock Prescaler an, werden also effektiv nochmal runtergeteilt. Durch welchen der 9 Möglichen diskreten Werte, legt das CLKPR (Clock Prescale Register) fest. Dieses ist ein I/O-Register, und wird beim Reset des Controllers immer mit einem bestimmten Wert beschrieben (man kann es aber zur Laufzeit des Programmes umschreiben (zB um Strom zu sparen)) - mit welchem?
Das legt die CKDIV8-Fuse fest. Ist sie gesetzt, beträgt der Wert 8 (der Controller läuft dann effektiv mit 8/8=1MHz), ist sie nich gesetzt, beträgt der Wert 1 (also 8/1=8MHz).

Am einfachsten kann man das herausbekommen, indem man 'n Timer 'n Bein zappeln läßt (zB PWM), und da 'ne bestimme Frequenz erwartet - 1Hz LED-blinken...

Am Rande: der Tiny45 (ohne V) kann mit der internen PLL auch mit internen 16MHz betaktet werden - eigentlich sollte das auch mit dem V gehen, allerdings ist der damit jenseits seiner Funktionsgarantie. Keine Ahnung, ob das schon mal wer ausprobiert hat.

Und nochwas: wegen dem Tiny4/5/9/10 im anderen Thread - der hat keine Fusebits für die ClockSource, startet immer mit effektiv 1MHz intern. Da kann man dann nicht nur den Hauptprescaler zur Laufzeit umsetzen, sondern auch die Clocksource (wobei der nur zwischen 'ner externen Clock, dem internen 8MHz Oszi und dem 128kHz-Watchdog-Oszi wählen kann. Bei nur 4 I/Os, von denen einer meist Reset ist macht ein Quarz sicher nicht viel Sinn)

EDIT: per Bootloader solltest Du aber keinen Zugriff auf die Fusebits haben. Das geht nur über HVPP und SPI-ISP (und beim Tiny4/5/9/10 über TPI/HV-TPI). Zu dWire & co. muß @TommyB was sagen - hab ich keine Ahnung von.
Den Hauptprescaler kann die Arduino-IDE dann wie gesagt zur Laufzeit umschalten lassen...
 
Zuletzt bearbeitet:
Auch debugWire kann die Fuses nicht verändern. Einzige Ausnahme ist das dW Bit selbst damit es sich selbst wieder deaktivieren kann und somit ISP wieder frei schaltet. Sprich die Fuses können nur über ISP/TPI bzw. HVSP/HVPP gesetzt werden.

Ich weiß jetzt garnicht genau... War die Arduino Geschichte nicht mit Bootloader? Damit man keinen Programmer braucht? Einige Tinys unterstützen das doch garnicht. ... Wobei ... @LotadaC würde ich das auch zutrauen einen USB Stack auf nen ATtiny4 zu quetschen. Hmm, 6 Pins, 2 weg für VCC und GND, 2 weg für D+ und D-... Bleiben noch 2 über. RxD und TxD? :D
World smallest USB to UART Chip? ^^
 
Für die ausführliche Erläuterung erst einmal vielen Dank! Das bringt so langsam Licht ins Dunkel.

In der Arduino IDE gibt es den Menüpunkt "Werkzeuge-Bootloader brennen" Natürlich bringt das beim Tiny nichts, weil er mit dem nächsten Flashen wieder überschrieben wird (zumindest habe ich das so verstanden) aber es werden wohl die Fuses so geändert, dass der Werksfrische Tiny dann auf 8 Mhz intern läuft. Das wird dann wohl die genannte "CKDIV8-Fuse" sein, nehme ich an.

Wenn der Tiny werksseitig mit 1Mhz läuft, dann werde ich das erst mal so belassen, denn damit könnte er ja auch bei 2V noch stabil arbeiten. Den Tip mit dem 1Hz LED-Blinker habe ich mal probiert. Einfach und effektiv! Ein guter Tip. So kann man gut überprüfen, wie schnell der Tiny aktuell läuft.
 
Den Tip mit dem 1Hz LED-Blinker habe ich mal probiert. Einfach und effektiv! Ein guter Tip. So kann man gut überprüfen, wie schnell der Tiny aktuell läuft.
Noch einfacher isses, mit 'nem richtigen Programmer die entsprechenden Fusebits auszulesen... aber mit dem blinken lassen sieht mans wirklich...
...Einige Tinys unterstützen das doch garnicht. ... Wobei ... @LotadaC würde ich das auch zutrauen einen USB Stack auf nen ATtiny4 zu quetschen. Hmm, 6 Pins, 2 weg für VCC und GND, 2 weg für D+ und D-... Bleiben noch 2 über. RxD und TxD? ...
Hui... ohne jegliche Kommunikationsschnittstelle, mit nur einem Timer (ok, eventuell kann man den Watchdog-IRQ zweckentfremden, und den ADC beim Tiny5/10), und dann mit max 8MHz Systemtakt...ne... da glaub ich nicht dran... schon gar nicht bidirektional...
Zum Bootloader: eigentlich sollte sich sowas in jedem AVR realisieren lassen, der SPM (also das beschreiben des Flash zur Laufzeit unterstützt (der Tiny4/5/9/10 zB nicht, der kann zwar auf den Flash (unter anderem) wie auf SRAM zugreifen, aber nur lesend(!))
AFAIK war das mit den AVR mit angegebenen Bootloader-Support eher so, daß bei denen SPM nur dann ausgeführt wird, wenn SPM in einem bestimmten Flash-Bereich steht (eben den dafür vorgesehenen). Es gibt aber auch AVR wo nix zum Bootloader steht, die aber trotzdem SPM beherrschen (der Tiny2313 zB). Generell empfiehlt sich dann die Verwendung einer Hardware-Kommunikationsschnittstelle - zwar nicht zwingend, aber es reduziert den Code-Aufwand des Loaders erheblich.
In der Arduino IDE gibt es den Menüpunkt "Werkzeuge-Bootloader brennen" Natürlich bringt das beim Tiny nichts, weil er mit dem nächsten Flashen wieder überschrieben wird (zumindest habe ich das so verstanden) aber es werden wohl die Fuses so geändert, dass der Werksfrische Tiny dann auf 8 Mhz intern läuft.
Wie gesagt: Die Fusebits kann ein AVR nicht selbst umschreiben. Bei der CKDIV8-Fuse wird nur festgelegt, mit welchem SystemClockPrescaler der AVR startet, OutOfTheBox halt mit effektiv 1MHz Systemtakt. Deine IDE kann natürlich in jedes Programm den Code miteinfügen, der dann gleich am Anfang (aber eben erst zur Laufzeit) den Vorteiler umstellt. Dann startet er erstmal auch nur mit 1MHz, schaltet aber mit den ersten Instruktionen auf 8MHz hoch.
Zweitens: Beim beschreiben des Flash muß nicht zwingend der ganze Flash beschrieben/gelöscht werden. Die IDE kann also den Bereich, den sie für den Loader vorgesehen hat unangetastet lassen.
Drittens: Hast Du dann aber das klassische Henne-Ei-Problem: Wenn der Controller aus dem Reset kommt, führt er das in ihm steckende Programm aus (welcher Mist das auch immer ist). OutOfTheBox steht nix drin -> der tut also gehorsam nichts. Ist bereits ein Loader programmiert, wird dieser ausgeführt.
Die konventionellen Programmierverfahren (serielles/paralleles SPI, TPI, PDI) und dWire nutzen den Reset, um den Programmiermodus zu erzwingen (bei AVR, wo der /Reset zum I/O gefused wurde, löst ein +12V-Pegel am Pin trotzdem einen Reset aus und erzwingt dann einen speziellen High-Voltage-Programmiermodus).
Wenn der Controller sich selbst, "von innen heraus" neu programmieren soll, muß das durch ein bereits vorhandenes Programm ausgelöst/umgesetzt werden.
 
Ganz schön umfangreich, diese kleinen Käfer. Da raucht einem Einsteiger echt der Kopf... Aber vielen Dank für die Mühe, die Du Dir gibst!
Als Programmer hab ich neben dem Arduino, mit dem wohl sehr viele anfangen, inzwischen einen AVR ISP MK2.

Dazu habe ich mal eine Frage. Anfänglich habe ich mich gefragt, aus welchem Grund die USB-Versorgungsspannung nicht am µC angelegt wird. Nach viel Sucherei glaube ich es nun verstanden zu haben. Das Gerät misst über den Vcc Pin, mit welcher Spannung die Schaltung, bzw. der µC läuft und stellt dann die Spannung, mit der programmiert wird, entsprechend ein. Somit wäre es möglich, einen µC auch innerhalb einer Schaltung zu programmieren, die beispielsweise mit 2,5V läuft und deren Bauteile nicht mehr als diese Spannung vertragen. Würde dort mit 5V programmiert, würden die Bauteile beschädigt. Habe ich das richtig verstanden?
 

Ü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)