Reaktives Licht mit Atmel AVR

[orotl]

Ja, der berühmte 100 nF-Kondensator... So haben wir es vor Jahrzehnten auch noch gelernt.

Ja und Nein. Mein Kollege bezeichnet diese Kondensatoren bei seinen Vorträgen immer als 'Angstkondensatoren' und lässt sie bei seinen Entwicklungen klarerweise immer weg. Allerdings nur dann wenn auf einer Leiterplatte ein funktionierendes, breitbandig entkoppeltes Stromversorgungssystem vorhanden ist, davon kann aber hier ja leider nicht die Rede sein
Im Gegenteil: hier hat er es als 'sträfliches Versäumnis' bezeichnet den Kondensator nicht einzubauen.
Gerade in Temperaturextrembereichen und/oder bei schwächelnden Batterien kann es dadurch zu unnötigen sporadischen Ausfällen kommen.
Das dI/dt schert sich leider nicht darum ob die CPU jetzt mit 10Mhz oder mit 128kHz getaktet wird.

Wer mag, kann den ja mit einbauen; ich werde ihn auf jeden Fall beim Erstellen des aktuellen bzw. fertigen Schaltplanes mit berücksichtigen.

Danke

Und zum Thema PWM: Ich werde den Vorwiderstand nun auf jeden Fall in der Schaltung lassen, da die BOD nicht aktiv ist. Sollte der µC bei Unterspannung nämlich Mist bauen, könnte das ohne Rv evtl. den Tod der LED zur Folge haben.

ACK

Nicht uninteressant! ;-) Aber einen Systemwechsel und/oder weitere strombezogene Optimierungen habe ich nun nicht mehr vor.

Ja klar, ist ja auch nicht wirklich nötig, aber vielleicht gibt es ja Leute die mit 3 Jahren Batterielaufzeit noch nicht glücklich sind

Aber sage mal: Wo sind eigentlich die ganzen anderen 'Tiny-Konstrukteure' hier, die auch mal ähnliche Schaltungen angekündigt, aber nie fertig- bzw. hier eingestellt haben?

Na, hab mich ja eh gemeldet
Leider bin ich über meinen (zwar funktionierenden) Prototypen aus Zeitgründen noch nicht hinausgekommen.
Allerdings ... nachdem ich deine Schaltung gesehen habe ... knüll .. wegwerf

danke und lg, orotl

 

[Sir Vivor]

Moin alle,

nachdem ich nun schon öfter per PM gefragt wurde, wie das mit der Programmierung der AVR's bzw. Tiny's so funktioniert, möchte ich an dieser Stelle mal die Gelegenheit nutzen und ein Art kleines 'How-To' dazu vorstellen.

Bitte lest Euch diesen Beitrag dazu genau durch (insbesondere die 'AVR-Neulinge') und stellt danach dann Fragen, falls sich welche ergeben, hier in diesem Thread. Auf diese Art und Weise haben dann alle etwas davon, ok?

Zum Programmieren des ATtiny13(V) braucht man folgendes:

1. Einen ATtiny13(V) ;-) (z.B. von Reichelt oder CSD)
2. Ein Steckbrett (Breadboard) oder eine Platine, auf der der Tiny dann seinen Platz zum Programmieren findet
3. Einen Computer mit (paralleler) Druckerschnittstelle
4. Einen Programmieradapter für die (parallele) Druckerschnittstelle
5. Bascom-AVR (kostenlos bis 2 KB Code)
6. Ein Programm

Zu 1.: Die AVR's kann man heutzutage fast überall kaufen; schaut dazu mal in's Internet, fragt einen Kumpel oder benutzt die beiden von mir angegebenen Links (CSD ist oft preiswerter als Reichelt, insbesondere bei den Versandkosten!). Der Tiny13(V) läuft übrigens auch ohne externen Quarz; er ist 'fabrikmäßig' auf den internen Oszillator mit 1 MHz eingestellt.

Zu 2.: Ein Steckbrett (Engl.: Breadboard) ist zum Programmieren natürlich praktischer als eine (gelötete) Platine, da man damit auch blitzschnell mal andere AVR's programmieren kann. Nachteil: Es kostet Geld! Nützlich ist es, wenn man plant, öfter mal einen AVR zu programmieren und/oder eine Testschaltung aufzubauen. Erhältlich ist so etwas in jedem guten Elektronik-Laden.

Zu 3.: Wenn der nicht vorhanden ist, wie könnt Ihr das hier dann überhaupt lesen??? Ja, ich weiß. Ihr seid gerade bei einem Kumpel oder im Internetcafé. Oder Euer Boß schaut Euch gerade über die Schulter - dreht Euch doch mal vorsichtig um... ;-)

Zu 4.: Es gibt grundsätzlich zwei Möglichkeiten, einen AVR zu programmieren: Über die parallele (LPT1) oder die serielle (RS232) Schnittstelle eines Computers. Ja, stimmt, USB geht auch. Aber dazu braucht man spezielle (und damit auch oft sehr teure) Programmierboards. Also beschränken wir uns nur auf 'parallel' und 'seriell'. Sollte das erste wider Erwarten nicht wie bei mir funktionieren, werde ich das zweite in einem gesonderten Beitrag näher erläutern. Ich habe mir einfach diesen Low-Cost-Adapter (SP12-kompatibel) für die parallele Schnittstelle nachgebaut:

Er besteht aus einem 25 pol. Stecker, zwei Widerständen (2 x 220 Ohm) sowie fünf Drähten. Mehr nicht.

Zu 5.: Zunächst müßt Ihr Bascom herunterladen und installieren. Dann werden noch ein paar Einstellungen vorgenommen und schon kann's losgehen. Mit Bascom kann man nicht nur Programme schreiben, sondern diese dann auch direkt zum µC übertragen.

Zu 6.: Hier mein bisheriges Programm (Copy & Paste):

'============================================================
'
' ************************************
' ***                              ***
' *** Reaktiv-Tiny v0.1 20/11/2005 ***
' ***                              ***
' ************************************
'
' µC: ATtiny13
' +Ub: 3,43 V
' I: 58 µA
' Reichweite Dorcy:
' Reichweite 4D-MagLite:
'
'============================================================
'
$regfile = "ATtiny13.DAT"
$crystal = 113000                       'Reale Frequenz des internen 128kHz-Oszillators
'
Config Portb = &B00011000               'Pinb.3 und .4 auf 'Ausgang', Rest auf 'Eingang' schalten
Portb = &B11100111                      'Pullups zuschalten, außer für Pinb.3 und .4
'
Stop Adc                                'A/D-Wandler abschalten, um Strom zu sparen
Stop Ac                                 'Analog-Komparator abschalten, um Strom zu sparen
'
Dim A As Byte
Dim Hell_dunkel As Bit
'
Do
'
Gosub Led_abfrage
'
If Hell_dunkel = 0 Then
    For A = 1 To 10
        Portb.3 = 1
        Waitms 50
        Portb.3 = 0
        Waitms 500
    Next A
End If
'
Loop
'
Led_abfrage:
Portb.3 = 0                             'Portb.3 auf Masse schalten
Portb.4 = 1                             'Portb.4 auf +Ub schalten, um die LED zu 'laden'
Waitus 1                                'Ladezeit 1 µs, kann ggf. noch verkleinert werden
Config Portb.4 = Input                  'Portb.4 nun zwecks Abfrage der LED-Ladung auf 'Eingang' schalten
Portb.4 = 0                             'Pullup abschalten, sonst geht's nicht!
Waitus 1500                             'Entladezeit 1500 µs - je kleiner, je unempfindlicher
Hell_dunkel = Pinb.4                    'Ladezustand einlesen
Config Portb.4 = Output                 'Portb.4 wieder auf Ausgang schalten
Portb.4 = 0                             'Portb.4 auf Masse schalten
Return
'
End

Wird die LED angeleuchtet, gibt sie zehn kurze 'Lichtblitze' zurück. Falls sich gar nichts tut, solltet Ihr ggf. mal ihre Polarität checken.

Alles weitere folgt in den nächsten Beiträgen zum Thema!

Viele Grüße,

Sir Vivor

P.S.: Es mag sein, daß es schnellere, bessere, optimalere oder 'Was-Weiß-Ich-Nicht'-Möglichkeiten gibt, Programme für AVR's zu erstellen bzw. sie zu programmieren. Aber dieser Weg ist nahezu 'idiotensicher'. Und als ein solcher weiß ich somit, wovon ich rede... ;-)

 

[Lotti]

Moin,

Supi! Auf diese Anleitung habe ich gewartet .

zu Punkt 4. wäre es vielleicht nützlich zu wissen, welche Pins denn nun notwendiger Weise mit der paralellen Port verbunden werden müssen. Dein Schaubild ist ja umfangreicher als notwendig.

Gruss Volkmar

 

[orotl]

Danke Sir Vivor!

Vielleicht noch zwei weitere Links mit viel Lesestoff zu dem Thema:
http://www.mikrocontroller.net/
http://www.avr-asm-tutorial.net/index.html

orotl

 

[Sir Vivor]

Jetzt ich wieder... ;-)

Hier nun der aktuelle Schaltplan:

Und für Lotti der Plan, wie der Programmieradapter an die Schaltung angeschlossen wird:

Als nächstes folgt, wie man in Bascom den Programmieradapter als 'Brennhardware' einstellt sowie das Setzen der sog. 'Fuses' beim Tiny.

Es grüßt...

...Sir Vivor

 

[Monty]

Was macht das Gerät tagsüber? Blinkt es dann ständig?

 

[papa.joe]

Als nächstes folgt ...

Ich will hier einfach mal Danke sagen. Nicht nur für die tolle Entwicklung sondern vor allem für das Teilen dieser genialen Idee mit der Community! Danke.

Gruß papa.joe

 

[Windi]

Was macht das Gerät tagsüber? Blinkt es dann ständig?

Die Frage habe ich Sir Vivor auch schon gestellt.
Die LED blinkt nur wenn sie direkt (also quasi senkrecht auf die Leuchtfläche) angestrahlt wird. Normales Sonnenlicht soll keinen Einfluss darauf haben. Ggf. muss man halt in das Programm noch eine Tag/Nacht-Abfrage einbauen.

 

[Starglider]

Ggf. muss man halt in das Programm noch eine Tag/Nacht-Abfrage einbauen.

Die Software könnte auf einen Übergang von hell nach dunkel warten. Das Blinken würde dann tagsüber gar nicht starten, weil es eben nicht dunkel (genug) wird und nachts est, wenn die Suchlampe nicht mehr direkt auf die LED leuchtet. Dann ist das Blinken auch besser sichtbar.
Spannend wäre in diesem Zusammenhang natürlich das Verhalten in der Dämmerung...

Man könnte der Schaltung aber auch eine zweite LED spendieren, die man nur als Sensor für die Umgebungshelligkeit verwendet.

@Sir Vivor:
Hast du mal ausprobiert wie diese Schaltung auf ein Blitzlicht reagiert?

 

[Sir Vivor]

Danke.

Bitte, gern geschehen! ;-)

Die Schaltung ist im Moment noch eher ein 'Helligkeitsdetektor': Ist es hell genug (ob nun Taschenlampe oder Tageslicht), dann blinkt die LED. Die Ansprechempfindlichkeit bzw. Auslöseschwelle ist in meinem Programm per Zeitschleife einstellbar (siehe Programmcode). Man kann sie auf 'hyper-empfindlich' einstellen, aber dann blinkt die LED eben schon bei normalem Tageslicht.

Zum jetzigen Zeitpunkt könnte man damit z.B. einen 'Nacht-Blinker' bzw. '-Blitzer' realisieren oder durch Programmergänzung (Stichwort 'Aktivierung bei Dunkelheit') ein stark verbessertes reaktives Licht.

Derzeit ist das Programm also, ohne eine Art programmierten Filter oder 'Dunkelsteuerung', für seinen eigentlichen Zweck noch nicht ganz optimal.

EDIT:

Man könnte der Schaltung aber auch eine zweite LED spendieren, die man nur als Sensor für die Umgebungshelligkeit verwendet.

Ja, aber wozu?

Hast du mal ausprobiert wie diese Schaltung auf ein Blitzlicht reagiert?

Nein. Meinst Du das als eine Art 'Geschwindigkeitstest'?

Viele Grüße,

Sir Vivor

 

[Windi]

Ich denke die einfachste Variante der Tag/Nacht-Unterscheidung könnte wohl in der Art sein:

Sensorzustand1 einlesen und speichern.
nach 30 Sekunden Sensorzustand2 einlesen.
Wenn Sensorzustand1 = hell und Sensorzustand2 = hell dann Tag
Wenn Sensorzustand1 = dunkel und Sensorzustand2 = dunkel dann Nacht.

Wenn Tag dann sperre Blinker.
Wenn Nacht dann gib Blinker frei.

 

[Sir Vivor]

Da hast du recht, Windi, gute Idee!

Ich glaube nur, daß die Zeit zwischen zwei Zustandsabfragen wesentlich größer sein müßte (so ca. 10 bis 30 Minuten), da sich sonst leicht ein unsicheres bzw. falsches Auslöseverhalten ergeben könnte. Denk mal an die Situation 'Sonne-Wolken-Sonne'... Statt die Abfragezeit zu erhöhen, könnte man auch die Anzahl der Abfragen heraufsetzen:

hell-dunkel-hell-dunkel-hell -> Starke Wetteränderungen am Tag
hell-dunkel-dunkel-dunkel-dunkel -> Übergang zur Nacht, Nacht

Weiterer Gedanke: Wenn man im Programm die LED als Sensor auf 'hyper-empfindlich' stellt, wird sie 'dunkel' eh nur noch dann melden, wenn es wirklich stockdunkel ist. Man könnte dann zur Sicherheit noch eine Zeitschleife starten, nach deren Ablauf die Schaltung erst 'scharf' wird.

Und jetzt sag' noch mal einer, wir haben keine guten Ideen! ;-)

 

[Starglider]

Hast du mal ausprobiert wie diese Schaltung auf ein Blitzlicht reagiert?

Nein. Meinst Du das als eine Art 'Geschwindigkeitstest'?

Jein. Wenn man die Schaltung z.B. mit einem mitgebrachten Fotoapparat auslösen kann wäre das sehr praktisch. Nicht jeder Nachtcacher ist mit Monster-Taschenlampen unterwegs, auch wenn dieses Forum manchmal den Eindruck erweckt.

@windi:
So ähnlich hatte ich mir das auch gedacht.
Wenn man nur mit einem Sensor misst müsste man sobald "Nacht" erkannt ist, die Pause zwischen den Messungen deutlich verkleinern.
Sonst verpassen wir ständig den Moment, wo die Cacher-Suchlampe vorbeischaut.
Und dann müsste die Logik für die Tag-Erkennung irgendwie anders sein, weil wir ja nicht mehr alle 30 Sekunden messen sondern z.B. alle 0,25 Sekunden.
Wenn dann bei 120 aufeinanderfolgenden Messungen ständig "hell" herauskommt wäre damit wieder Tag und man geht zurück in den 30-Sekunden-Takt.

Da könnte es aber Probleme mit dem Schattenspiel der Bäume geben.
Vielleicht wäre so etwas besser wie: Wenn von den letzten x Messungen mindestens y "hell" ergeben haben, dann ist Tag.

 

[Windi]

Und jetzt sag' noch mal einer, wir haben keine guten Ideen! ;-)

In Gedanken seh ich schon den ersten Atmel-Only-Cache vor mir. :twisted:

Um den Cache zu lösen muss man erst einen Prozessor programmieren und in eine kleine Schaltung einbauen. Am Cache befindet sich dann eine weitere Schaltung die nur dann anspringt (z.B. Erkennen einer bestimmten Blinksequenz) wenn der richtige "Sender" (also die Schaltung) vorhanden ist. Erst dann rückt der Empänger die Endkoordinaten raus.

 

[Windi]

Wenn man nur mit einem Sensor misst müsste man sobald "Nacht" erkannt ist, die Pause zwischen den Messungen deutlich verkleinern.
Sonst verpassen wir ständig den Moment, wo die Cacher-Suchlampe vorbeischaut.
Und dann müsste die Logik für die Tag-Erkennung irgendwie anders sein, weil wir ja nicht mehr alle 30 Sekunden messen sondern z.B. alle 0,25 Sekunden.

Genau so habe ich mir das auch vorgestellt. Nur die Unterscheidung zwischen Tag und Nacht soll alle 30 Sekunden stattfinden.
Der eigentliche Abtastvorgang bleibt (zumindest nachts) im kurzen Intervall. Damit eben auch schnelle Schwenker mit der Taschenlampe erkannt werden können.

 

[Mika Mifizu]

Die LED blinkt nur wenn sie direkt (also quasi senkrecht auf die Leuchtfläche) angestrahlt wird. Normales Sonnenlicht soll keinen Einfluss darauf haben. Ggf. muss man halt in das Programm noch eine Tag/Nacht-Abfrage einbauen.

Vielleicht hilft es, eine zweite LED in der gleichen Art und Weise, aber senkrecht dazu, einzubauen und ebenfalls abzufragen.
Melden beide LEDs "Licht", ist es Tag, weil diffuses Licht von überall her kommt.
Ist nur eine von beiden hell, ist es Nacht und die Schaltung tut wie es programmiert ist.

Gruß
Mika

 

[Bara68]

Erstmal vielen herzlichen Dank an Sir Vivor für diese überragende Schaltung.

Um zwischen Tag, Nacht und dem Signal einer Taschenlampe unterscheiden zu können benötigen wir zwei aufeinander folgende Abfragen. Das Ergebnis dieser Abfragen seht ihr hier:

+-------------------------------------------------------+
|1. Abfrage | 2. Abfrage | Ergebnis                     |
+-------------------------------------------------------+
|Hell       | Hell       | Tag                | LED aus |
|Hell       | Dunkel     | Dämmerung / Signal | LED an  |
|Dunkel     | Hell       | Dämmerung / Signal | LED an  |
|Dunkel     | Dunkel     | Nacht              | LED aus |
+-------------------------------------------------------+

Ihr wollt, dass bei Dämmerung die LED nicht aktiv wird? Dazu muss eine 3. Abfrage mit einer anderen Lichtempfindlichkeit hinzugefügt und richtig ausgewertet werden.

Ich wünsche Euch viel Erfolg beim Experimentieren und Programmieren!

 

[radioscout]

Dann wird es wohl nicht mehr lange dauern, bis jemand die LED als lichtgesteuerte Kapazitätsdiode verwendet.

 

[Windi]

HAb vorhin die Mail bekommen dass meine bestellten Bauteile bei CSD heute rausgegangen sind. Also morgen mal das Steckbrett rauskramen.

 

[Sir Vivor]

Moin,

Vielleicht hilft es, eine zweite LED in der gleichen Art und Weise, aber senkrecht dazu, einzubauen und ebenfalls abzufragen.

Die Idee ist gut, nur möchte ich das gern mit einer LED hinbekommen. In allen analogen Schaltungen nimmt man ja auch nur einen LDR.

Erstmal vielen herzlichen Dank an Sir Vivor für diese überragende Schaltung.

Bitte schön oder wie der Hamburger sagt: "Dor nich' för!" Das Lob für die Grundidee gebührt aber dennoch den Ingenieuren von Mitsubishi; ich hab's lediglich auf die AVR's portiert...

Dann wird es wohl nicht mehr lange dauern, bis jemand die LED als lichtgesteuerte Kapazitätsdiode verwendet.

Ähm, genau das tu'n wir ja jetzt schon. Nur messen wir nicht deren Kapazität als solche, sondern schauen lediglich nach einer festen Zeit nach, ob die Kapazität noch ge- oder schon entladen ist. Bisher habe ich mich bewußt für dieses Verfahren entschieden, da eine absolute oder relative Kapazitätsmessung programmtechnisch wesentlich aufwendiger zu realisieren wäre. Und anhand der diversen unterschiedlichen LED's, die von den Leuten verbaut werden/würden, wäre eine sichere Reproduzierbarkeit bezüglich der Funktion so wohl nicht ohne weiteres möglich. Man müßte das Programm dann wahrscheinlich für jede LED anpassen. Die Kapazitätsmessung hätte aber auch einen großen Vorteil: Man bekäme 'analoge' Helligkeitswerte; eine 'Hell-Dunkel'-Steuerung wäre dann wesentlich einfacher zu realisieren.

HAb vorhin die Mail bekommen dass meine bestellten Bauteile bei CSD heute rausgegangen sind. Also morgen mal das Steckbrett rauskramen.

Cool! 8) Denn gleich folgt das kleine 'Bascom-AVR-How-To', so daß Du morgen sofort 'los schrauben' kannst!

Wer ist denn hier eigentlich schon am Basteln/Programmieren?

Es grüßt...

...Sir Vivor