Sturzi's Arduino-Bastel-Projekt #1 - Es werde Licht

Zitat von andysan

Meine Idee (damit ich mir sicher gewesen wäre die Befehle verstanden und selbstständig erweitert zu haben), war es ja eigentlich zwei LEDs mit zwei verschiedenen, zufälligen Parametern zB:(millisToWait = (random(100,2000)) und (millisToWait = (random(1000,10000))zu programmieren die überschneidend sein könnten.

Andy, ich habe dir die Antwort dazu schon gepostet. Aber unsere letzten Beiträge haben sich scheinbar gekreuzt.

Zitat von ch-schmalspur

Danke Röbi für Deine schrittweise Anleitung.

Ich habe heute einen Starterkit bestellt und bin bis zum Erhalt nur "Theorie"-Schüler

Freue mich aufs Ausprobieren.

Cool!

Ja, es ist so wie Markus schreibt.

Du hast dich bei der Deklaration der beiden Variablen auf Zeile 1 und 3 vertippt.

Auf Zeile 15 und 18 meldet das System nun Fehler (die Zeilen sind farbig hinterlegt), weil es die beiden Variablen nicht kennt.

Die Korrektur musst du auf den Zeilen 1 und 3 machen (...Change und nicht ...Chance).

Zitat von andysan

Schreibfehler behoben und es funktioniert wunderbar.

Freut mich für dich!

Zitat von andysan

Ich dachte der Fehler sei bei den rot hinterlegten Zeilen.

Aus der Sicht des Compilers ist der Fehler schon bei den rot hinterlegten Zeilen 15 und 18. Der Compiler weiss ja nicht, dass es richtigerweise ...Change heissen sollte. Er hat das (für uns falsche) ...Chance auf den Zeilen 1 und 3 für bare Münze genommen und auf den Zeilen 15 und 18 Namen festgestellt, die er noch nicht kennt. Deshalb hat er dort gemotzt.

Zitat von Zosch

Starter-Kit heute bekommen und alles soweit ausgeführt.

Alles funktioniert!

Super! Es wird bald weitergehen.

Unabhängiges, zufallsgesteuertes Blinken mit zwei LEDs, Einschaltdauer und Ausschaltdauer unterschiedlich

Basierend auf dem letzten Programm machen wir jetzt ein paar Modifikationen.

- Wir wollen zwei LEDs unabhängig voneinander mit zufälligen Zeiten blinken lassen.

- Die Dauer des ausgeschalteten Zustandes soll im Mittel länger sein als die Dauer des eingeschalteten Zustandes.

- Wir werden symbolische Konstanten kennenlernen und diese wie die Profi-Programmierer sinnvoll anwenden.

Hier zu Beginn nochmals die Ausgangslage, also die letzte Version des Programmes:

Und jetzt die neue Version:

Für heute läuft mir die Zeit davon. Ich werde die Erklärungen zu den neuen Konstrukten erst morgen anbringen können.

Bis dann wäre es gut, wenn du das Programm nachvollziehen könntest. Probiere es zu verstehen, auch wenn die entsprechenden Erklärungen noch fehlen! Über Rückmeldungen bin ich froh. Fragen werde ich gerne beantworten, aber erst morgen.

Noch ein Hinweis für die Experten unter euch: Es ist klar, dass man so etwas besser mit Arrays löst. Aber ich will ja in kleinen Schritten vorrücken.

Also eine Version mit Arrays für beliebig viele LEDs demnächst in diesem Theater.

Andy GR, Giorgio, Urs, Oski: Vielen Dank für eure Rückmeldungen!

@Urs: Wenn es eine LED aus dem Starterkit ist, müsste sie normal hell leuchten. Ich vermute trotzdem, dass du einen zu grossen Widerstand erwischt hast. Die Farbcodes (farbige Ringe um den Widerstand) sind leider etwas verwirrend und häufig nicht eindeutig erkennbar. Aber beim 220 Ω Widerstand müsste der Farbcode mit zwei roten Ringen beginnen (oder enden, je nachdem wie du ihn hältst). Sonst miss ihn doch mal mit einem Multimeter.

Hier noch ein paar Erklärungen zur letzten Version:

Zeilen 1 bis 4: Hier definieren wir 4 symbolische Konstanten (dass sie konstant sind und bleiben, erkennt man am Wort const) mit sprechenden Namen und ordnet ihnen die zugehörigen direkten numerischen Werte zu. Beachte, dass sich diese Definitionen vor allen vorkommenden Funktionen befinden. Sie gelten damit für alles, was nachher kommt, d.h. in allen Funktionen. Innerhalt der Funktionen verwendet man die Konstanten über ihren Namen. Direkte numerische Werte (wie im vorhergehenden Beispiel) sollte man vermeiden.

Die Verwendung von symbolischen Konstanten hat mehrere Vorteile:

Wenn man später Anpassungen an den Werten machen muss, muss man nicht lange im Code suchen (bedenke, dass sich anspruchsvollere Programme über mehrere Seiten erstrecken können), sondern ganz oben zu Beginn.

Wenn man die gleichen Werte im Programm mehrmals braucht (wie hier auf den Zeilen 32 und 43, bzw. 34 und 45), muss man sie bei Anpassungen nicht an jeder Stelle ändern, sondern nur an einer.

Wenn man sich bei der Verwendung einer symbolischen Konstanten vertippt, motzt der Compiler und man korrigiert den Fehler. Wenn man sich jedoch bei der Verwendung eines direkten numerischen Wertes vertippt (z.B. 29000 statt 2000) merkt das der Compiler nicht und der Fehler tritt erst zutage, wenn man merkt, dass das Programm nicht das Richtige macht (vielleicht erst nach langer Zeit).

Deshalb: Vermeidet die Verwendung von direkten numerischen Werten innerhalb der Funktionen. Es gibt zu dieser Regel ein paar Ausnahmen, aber darauf will ich im Moment nicht eingehen.

Die beiden Funktionen changeStatus1() und changeStatus2() sind gleich aufgebaut. Ich werde die folgenden Anmerkungen nur für die Funktion changeStatus1 machen. Sie gelten natürlich genauso für die andere.

Zeile 29: Weil wir den neuen LED Status zweimal brauchen, wollen wir ihn nicht zweimal mit ! digitalRead(7) ermitteln, sondern nur einmal. Dafür speichern wir ihn in einer lokalen Variablen bool newStatus.

Dort wo wir nun den neuen Status brauchen (beim digitalWrite() und beim if) setzen wir einfach die lokale Variable newStatus ein.

Die lokale Variable newStatus hat in beiden Funktionen den gleichen Namen. Warum motzt da der Compiler nicht? Weil sie lokal sind. Wenn eine Variable innerhalb einer Funktion deklariert wird, gilt sie nur innerhalb dieser Funktion. Deshalb gibt es da keine Verwirrung.

Der Gegensatz dazu ist die Deklaration von Variablen vor den Funktionen, wie z.B. long millisToWait1. Solche Variablen gelten für das ganze Programm. Wenn wir auf diese Art zwei (oder mehr) Variablen mit dem gleichen Namen deklarieren würden, gäbe es vom Compiler eine Fehlermeldung.

Die Variable newStatus ist vom Typ bool. Das bedeutet, dass es eine binäre Variable ist. Sie kann nur zwei Werte annehmen, nämlich true und false.

Ja gopfridstutz, warum lässt sie sich denn jetzt plötzlich auf HIGH oder LOW setzen? Das ist, weil im Hintergrund vom Arduino-System HIGH zu true und LOW zu false gleichgesetzt wurde.

Zeile 31: Die if Anweisung kennen wir schon aus der Funktion loop(). Hier kommt ein neues Element dazu, das else. Es gibt hier zwei geschweifte Klammernpaare, das nach dem if und das nach dem else. Beim ersten (nach dem if) werden die Anweisungen ausgeführt, wenn die if-Bedingung zutrifft und beim zweiten (nach dem else) werden sie andernfalls (also wenn die Bedingung nicht zutrifft), ausgeführt.

Und zuletzt noch eine Erklärung zum == in der if-Bedingung. Das == ist ein Vergleichs-Operator. Dieser wird verwendet, um festzustellen, ob zwei Werte gleich sind.

Sehr, sehr, sehr wichtiger Hinweis:

Es gibt ja noch den Zuweisungs-Operator =, dem wir schon ein paarmal begegnet sind. Wir müssen pingelig darauf achten, dass wir die beiden nicht verwechseln. Das ist im C++ eine der häufigsten Fehlerquellen. Wenn wir in einer if-Anweisung schreiben if (newStatus = LOW) statt if (newStatus == LOW), macht unser Programm etwas ganz anderes. Der Compiler bemerkt den Fehler nicht. Das ist nicht ganz einfach zu verstehen. Don't worry! Für jetzt ist die Moral von der Gechicht: Immer höllisch aufpassen bei einer if-Anweisung, dass man nicht = verwendet, sondern ==.

Genug für heute, bevor die Köpfe zu rauchen beginnen!

Für diejenigen unter euch, die mit diesem Projekt zum ersten Mal mit Programmierung konfrontiert werden:

Wenn man programmieren lernt, ist es so gut wie unmöglich in jeder Lernphase alles Erklärte zu verstehen. Man muss damit leben können, gewisse Details einfach hinzunehmen, ohne sie zu verstehen. In der Regel werden sie später dann schon klar.

Andererseits ist es für mich auch nicht möglich, immer alles zu erklären, was für das Verständnis des aktuellen Programmes eigentlich nötig wäre. Ich müsste so viel schreiben, dass es kaum jemand mehr lesen würde.

Also, wenn etwas nicht klar ist, einfach so übernehmen, wie ich es programmiert habe. In einer späteren Phase "keit de Zwänzger plötzlich abe".