Der Ton macht die Musik, heißt es. Der Ton fehlt hier, hier haben wir nur den Liedtext
Keine Sorge, das war nicht böse gemeint und mir ist bewusst, dass du Anfänger bist. Es ist nur so, wenn man da viele Jahre drin ist, dann fällt es einem immer schwerer Einstiegshürden einzuschätzen. Ich kann mich nur dran erinnern, dass es gängige Praxis unter Anfängern war keinen Wert auf die Formatierung des Quelltextes zu legen, weil es für die Funktion keine Rolle spielt und eigentlich möchte man doch nur schnell ein funktionierendes Programm und keinen hübschen Programmcode. Das habe ich schon häufig so gehört. Ich selbst habe das nie so gesehen, ich habe von Anfang an versucht es ordentlich zu formatieren, tat mich nur schwer damit herauszufinden, was nun eine sinnvolle offizielle Strategie ist. Ich weiß auch nicht, wie du das grundsätzlich siehst (du hast dich diesbezüglich nie geäußert) und was dein Wissensstand ist. Und es ist sehr mühselig das alles umzuformatieren, weshalb es ärgerlich wäre das demnächst wieder zu tun. Ich wollte, dass der umformatierte Quelltext auch als gutes Lernbeispiel dienen kann, sprich "learning by
lesing". Formatierung von Programmcode ist wichtig, weshalb ich dir nur den Ratschlag geben kann einen erheblichen Anteil an Hirnschmalz und Arbeit da hineinzustecken, denn die Zeit sparst du wo anders wieder ein.
Ich merke aber, dass da generell wesentlich größere Wissenslücken sind, als ich erwartet habe. Ich denke, die sollten wir als erstes mal angehen, damit du besser selbstständig programmieren kannst.
Takeshi, ich begreif die Wahr Falsch Geschichte nicht.
Das ist eine gute Information, denn das ist absolut grundlegend. Nehmen wir eine if-else-Anweisung, die sieht wie folgt aus:
if(Aussage)
{
// führe aus, wenn Bedingung wahr
}
else
{
// führe aus, wenn Bedingung falsch
}Die Aussage wird auf Wahrheit geprüft, ob die Aussage wahr oder falsch ist. Nehmen wir an, du hast die Variable "test".
// Ist die Variable "test" gleich 2?
test == 2... prüft die Variable test und die Zahl 2 auf Gleichheit. Enthält die Variable test den Wert 2, dann ist die Aussage wahr, in allen anderen Fällen ist sie falsch.
// Ist die Variable "test" ungleich 2?
test != 2... prüft die Variable test und die Zahl 2 auf Ungleichheit. Enthält die Variable test den Wert 2, dann ist die Aussage falsch, in allen anderen Fällen ist sie wahr.
// Ist die Variable "test" kleiner als 2?
test < 2... prüft, ob die Variable test kleiner als die Zahl 2 ist. Enthält die Variable test den Wert 1, 0, -1 , -2, ..., dann ist die Aussage wahr. Für die Zahlen 2, 3, 4, ... ist sie falsch.
// Ist die Variable "test" kleiner als 2 oder gleich 2?
test <= 2... schließt den Wert 2 für "wahr" mit ein.
// Sinnlose Aussage, da immer falsch
1 == 2// Einfache Anwendung
// Der Inhalt von "betrag" ist immer positiv
int zahl;
int betrag;
zahl = 1; // Der Variable werden für den Test verschiedene Werte zugewiesen, kann auch "-5" sein.
if(zahl < 0)
{
betrag = -zahl;
}
else
{
betrag = zahl;
}Solche Aussage kann beliebig komplex sein. Zusammenhängede Aussagen können mit Klammern zusammengebunden und mit "and" verbunden werden. Beispiel:
if((zahl > -5) and (zahl < 5) and (zahl != 0))
{
print("Zahl liegt zwischen -5 und +5, ist aber nicht Null!");
}
else
{
print("Betrag von zahl ist größer oder gleich 5, oder aber Null!");
}Das geht noch weiter, aber ich denke bis zu dem Punkt ist das erst einmal ausreichend.
So weit klar?
Zum Thema einrücken hatte ich ja bereits was geschrieben. Du wirst zwei Varianten finden:
(Reihenfolge wegen besserer Lesbarkeit meins Beitrags gewählt)
int zahl = 0;
void loop()
{
if(irgendeineAussage)
{
zahl++;
analogWrite(fanPin, 100);
}
// weiterer Code
}int zahl = 0;
void loop() {
if(irgendeineAussage) {
zahl++;
}
// weiterer Code
}Die zweite ist die, die du verwendest, ist scheinbar bei Arduino verbreitet. Die erste wirst du ggf. auch mal antreffen. Da du aber die zweite gewohnt bist, bleiben wir jetzt dabei.
Du siehst, Funktionen und sogenannte Kontrollstrukturen (if/else, for, switch, while)) haben immer den Aufbau "name(argument)". Befehlen folgt ein Simikolon ";" und Kontrollstrukturen in der Regel weitere Anweisungen. Wenn es nur eine Anweisung ist, kann man sie einfach darunter schreiben. Sind es mehrere, müssen sie in geschweiften Klammern zusammengefasst werden und gelten für die Kontrollstuktur dann als "eine Anweisung", die ggf. ausgeführt wird, je nachdem, was im Argument der Anweisung steht. Ich rate wie gesagt dazu, IMMER geschweifte Klammern zu verwenden, auch wenn es nur ein Befehl ist, der danach ausgeführt wird. Sorgt einfach für weniger Fehler.
Einer Kontrollstruktur (oder die Definition eines Befehls wie "void temperaturberechnung()") ist somit immer eine öffnende und eine schließende geschweifte Klammer zugeordnet. Die öffnende schreibst du hinter den Befehl und die schließende natürlich weiter unten, aber immer auf gleicher Ebene eingerückt wie der Befehl/die Kontrollstruktur selbst. Wenn du eine Linie vom Anfang der Kontrollstruktur nach unten ziehst, landest du irgendwann bei der schließenden Klammer. Und alles bis zu der schließenden Klammer gehört zu dieser Kontrollstruktur. Alles innerhalb der Klammer ist weiter nach rechts eingerückt. Du solltest immer den gleichen Abstand pro Einrückung verwenden. Üblich sind 4 Leerzeichen oder ein Tabulator, wobei man die meisten Programme so einstellen kann, dass ein Tabulator als 4 Leerzeichen dargestellt wird.
Zeilen nur mit Kommentar werden eingerückt wie alles andere auch.
Und generell gilt: Versuche die Art, wie du es schreibst, als Regel zu definieren und wende sie immer gleich an. "Zwischen Befehl und runter Klammer steht (k)ein Leerzeichen", "zwischen runder Klammer und Argument steht (k)ein Leerzeichen" oder eben "eine öffnende runde Klammer nach einer geschlossenen geschweiften Klammer steht mit einem Leerzeichen direkt dahinter".
Die Arduino Software ist Freeware.
Das ist mir bekannt, ich muss nur ehrlich zugeben, ich wollte es nicht installieren. Ich hab das Zeug dann auf der Platte und sehe schon kommen, wie ich dann versuche das überhaupt zu installieren (benutze Linux), ein Projekt zu starten, einen passenden Controller oder ein Board zu wählen, bis ich dann mal den Code compilieren kann. Wenn es an vielen kleinen Sachen hakt (die ich alle zur Genüge kenne), neige ich dazu diese kleine Sache doch noch hinzubekommen und am Ende sitze ich Stunden dran.
Das stammt aus einem Ursprünglichen Code den ich übernommen habe. Da wurde mit 2 Case gearbeitet, im ersten Case war im Grunde der aktuelle Lüftercode und im Zweiten Case eine Lineare Lüfterreglung wenn bestimmte Situationen eintreten. Da ich es nicht besser wusste und es keine Fehler in der Prüfung gab, blieb er drin. Wenn es weg kann, umso besser :-)
Ah, alles klar! Dann kann das wirklich raus. So ist der Code gleich übersichtlicher.
Auf den Rest antworte ich ein anderes Mal, ist schon spät.
Übersicht
Hilfe
Suche
Kalender
Einloggen
Registrieren
Drucken