setup() wird nur einmal zum Programmstart ausgeführt. loop() wird 
endlos, ohne dein zutun, vom Arduino Framework aufgerufen. Innerhalb von 
loop() kein "while(true){}" da loop() sonst nicht mehr verlassen wird.

Du musst jetzt noch ein wenig Logik in loop() einbringen, damit Du 
keinen Dauerton erhältst.

Grüsse

> durch einen Interrupt starten bzw das Programm soll durch eine andere
> PWM gestartet werden!

Diese Sichtweise ist grundsätzlich falsch.
Denn: Dein Programm läuft ja schon längst!
Da gibt es nichts mehr zu starten.

Die einzige Frage die du dir stellen kannst lautet, ob du nicht 
innerhalb von loop() (welches ja laufend immer wieder aufgerufen wird) 
mit einem if eine Entscheidung triffst, die abhängig von deiner 
Variablen 'start' einen Programmteil ausführt oder nicht ausführt.

Und wie Markus schon geschrieben hat: loop() darf nicht in einer 
Endlosschleife hängen bleiben.

EGS schrieb:
> Karl Heinz Buchegger schrieb:
>> Und wie Markus schon geschrieben hat: loop() darf nicht in einer
>>
>> Endlosschleife hängen bleiben.
>
> void loop()
> {
>
> }
>
> Das ist ja in dieser Umgebung schon die Endlosschleife,

eben.
Die Schleife sitzt ausserhalb der loop().

> sogesehen das
> "main" aus anderer C-Programmierung.

Nö.
Auf einem Ardunio arbeitet man so, dass man ein main voraussetzt, 
welches so aussieht

int main()
{
  setup();

  sei();

  while(1)
  {
    loop();
  }
}

Hier steckt deine Hauptschleife, und der ganze Aufbau ist dir vorgegeben 
und liegt ausserhalb deines Einflussbreiches. D.h. in loop() kommt keine 
Endlosschleife rein, die erledigt der 'Aufrufer' von loop().


Wenn du schon das Arduino Framework benutzt, dann musst du MIT ihm 
arbeiten und nicht GEGEN es. Deine Schwierigkeiten zeigen, dass du 
unbedingt deinen Kopf durchsetzen willst, anstatt dich dem anzupassen, 
was dir das Framework vorgibt. Und so ein Framework kann stur sein :-)
Deine Ausdfürungen zu tone() sind für mich jetzt erst mal nicht 
verständlich, dein Verständnis von return ist fehlerhaft. Genauso wie 
dein Verständnis darüber, wie tone() arbeitet.

Düsendieb schrieb:
> Karl Heinz Buchegger schrieb:
>> Nö.
>> Auf einem Ardunio arbeitet man so, dass man ein main voraussetzt,....
>
> Wenn man aber aus Unwissen über diese schon existierende Hauptschleife
> noch eine While (1) Schleife in loop() einbaut, passiert doch auch
> nichts Schlimmes, oder?

Das weiß ich nicht, weil ich nicht weiß, was in der Hautschleife an 
diesen Stellen

  while( 1 ) {
 
    xxxx

    loop();

    xxxx
  }
}

sonst noch so alles passiert.
Irgendwo muss ja auch das Arduino Framework seine Buchhaltung machen. So 
Dinge wie zb. die laufenden Millisekunden oder auch das Abschalten eines 
Tones (um beim Thema zu bleiben) nachdem seine Dauer abgelaufen ist, 
machen sich ja nicht von alleine.
Gib dem Framework seine Chance, die Dinge, die es vor oder nach dem 
Aufruf von loop() machen will, auch zu tun. Im 'schlimmsten' Fall macht 
das Framework hier nichts, weil sowieso alles Interrupt gesteuert 
abläuft. Dann ist der scheinbar unnötige laufende Aufruf von loop() aber 
der geringere Beinbruch, als wie wenn im Framework irgendwelche Dinge 
nicht funktionieren, weil du nicht nach den Regeln spielen willst.

Düsendieb schrieb:
> Wenn man aber aus Unwissen über diese schon existierende Hauptschleife
> noch eine While (1) Schleife in loop() einbaut, passiert doch auch
> nichts Schlimmes, oder?

Das Arduino-Framework bekommt keine Rechenzeit mehr. Ich würde also 
damit rechnen, dass bestimmte Funktionen nicht mehr funktionieren. Das 
obige Hauptprogramm ist ja nicht vollständig, sondern da kommen noch die 
internen Funktionen des Frameworks dazu:

int main()
{
  aruino_intern_setup();
  setup();

  sei();

  while(1)
  {
    arduino_intern_loop();
    loop();
  }
}

Wenn Du in loop() eine Endlosschleife produzierst, wird 
arduino_intern_loop() nicht mehr aufgerufen. Alle Funktionen, die davon 
abhängen, funktionieren dann nicht mehr wie erwartet.

Düsendieb schrieb:
> Hallo Karl-Heinz,
> ich habe auch gerade meine ersten Arduino Erfahrungen gemacht und aus
> alter Gewohnheit das Programm mit der while(1) Schleife aufgebaut.
> Beschwert hat sich der Apparat nicht

Natürlich beschwert sich da keiner.
Was erwartest du vom Compiler? Dass er deine Programmlogik überprüft?

> und das Programm macht auch was ich
> erwartet habe.

Ach, weißt du was.
Macht doch was ihr wollt
Ich bin es leid, erwachsene Männer in der Programmierung erziehen zu 
müssen.

EGS schrieb:
> LCD()
> {
> LCD Befehle...
> return(); --> muss sein damit ich in loop wieder lande.
> }

Nö. Wenn die Funktion LCD() zu Ende ist, wird auch ohne explizites 
return automatisch zurückgesprungen. Was soll denn sonst passieren?

EGS schrieb:
> Fabian O. schrieb:
>> Nö. Wenn die Funktion LCD() zu Ende ist, wird auch ohne explizites
>>
>> return automatisch zurückgesprungen. Was soll denn sonst passieren?
>>
>>
>>
>> Beitrag melden Bearbeiten Löschen
>
> Die Arduino IDE macht wie schon gesagt daraus nen Sprungbefehl, mit der
> Anweisung "Return();" springt er an den Punkt von dem der Sprungbefehl
> aufgerufen wurde zurück.

Sorry.
Aber du redest einfach nur Unsinn.

Die IDE hast schon mal überhaupt nichts damit zu tun.
Und eine Funktion kehrt immer zu ihrem Aufrufer zurück. Entweder 
vorzeitig, wenn sie auf ein return trifft, oder wenn der Programmfluss 
durch die Funktion zu Ende ist. So gesehen hat jede Funktion an ihrem 
unteren Ende einen impliziten return.

Und das hat auch nichts mit Arduino zu tun, sondern das ist in der 
Programmiersprache C++ so festgelegt.

> Getestet mit

Keine Ahnung was du dir wieder eingehandelt hast, weil du nicht nach den 
Regeln spielen willst. Und ich wills auch nicht wissen.
Aber hör bitte auf hier Unsinn zu verzapfen.

Dann schaut mal dort nach:
http://arduino.cc/en/Tutorial/WhileLoop

EGS schrieb:
> Karl Heinz Buchegger schrieb:
>> Keine Ahnung was du dir wieder eingehandelt hast, weil du nicht nach den
>>
>> Regeln spielen willst. Und ich wills auch nicht wissen.
>>
>> Aber hör bitte auf hier Unsinn zu verzapfen.
>
> Sorry aber leider scheinst du nicht zu wissen was die Arduino IDE ist.
> Das ist dein Interpreter der daraus den Programmcode compiliert.

Ja, genau
(Facepalm)


> Lies bitte erst die Doku zu den Arduinos bevor du mir irgendwas
> unterstellst.

Das würde ich dir als Arduino-Programmierer erst mal sehr ans Herz 
legen.

http://arduino.cc/en/Reference/loop

Wo siehst du hier in der Doku, dass in loop eine while Schleife 
stattfindet?

http://arduino.cc/en/Tutorial/Sketch

Scroll runter zu "Setup und Loop"
Welchen Teil von
" The loop() function is called over and over and is heart of most 
sketches."
verstehst du nicht?

Karl Heinz Buchegger schrieb:
> Wo siehst du hier in der Doku, dass in loop eine while Schleife
> stattfindet?

Hier z.B.: http://arduino.cc/en/Tutorial/WhileLoop

Code Ausschnitt:

void setup() {
  // set the LED pins as outputs and the switch pin as input:
  pinMode(indicatorLedPin, OUTPUT);
  pinMode (ledPin, OUTPUT);
  pinMode (buttonPin, INPUT);
}

void loop() {
  // while the button is pressed, take calibration readings:
  while (digitalRead(buttonPin) == HIGH) {
    calibrate(); 
  }
  // signal the end of the calibration period
  digitalWrite(indicatorLedPin, LOW);  

Frank Frank schrieb:
> Karl Heinz Buchegger schrieb:
>> Wo siehst du hier in der Doku, dass in loop eine while Schleife
>> stattfindet?
>
> Hier z.B.: http://arduino.cc/en/Tutorial/WhileLoop

ACh geh bitte, Frank.

Da gehts doch um ganz was anderes.


> void loop() {
>   // while the button is pressed, take calibration readings:
>   while (digitalRead(buttonPin) == HIGH) {
>     calibrate();
>   }

hier wird so lange gewartet, bis die Kalibrierung fertig ist.
Das hat doch überhaupt nichts damit zu tun, ob man jetzt den kompletten 
Inhalt von loop in eine Endlosschleife packt,

void loop()
{
  while( 1 ) {

    xyz

  }
}

oder ob man die Endlossschleife vom Aufrufer

void loop()
{
  xyz
}

erledigen lässt.

Steht doch auch in dem von dir verlinkten Beispiel: solange die Schleife 
läuft, geht nichts anderes mehr.
Nicht alles was hinkt, ist auch ein Argument.

EGS schrieb:
> Karl Heinz Buchegger schrieb:
>> Und das hat auch nichts mit Arduino zu tun, sondern das ist in der
>>
>> Programmiersprache C++ so festgelegt.
>
> C und C++ sind zwar nahe Verwandte aber die Arduino Programmiersprache
> ist eher C als C++ vermenge das mal nicht.

Es gibt kein 'Eher'.
Entweder du programmierst C oder du programmierst C++

Gibt es in C Klassen?
Nein
Gibt es im Arduino Framework Klassen?
Ja

Kann daher das Arduino Framework und damit auch Arduino Programme C 
sein?`
Nein

> Nixc anderes habe ich gesagt

Was du behauptet hast ist, dass du hier

void loop()
{
LCD();

 weitere Anweisungen... //werden nur abgearbeitet wenn ich aus LCD() 
zurückspringe (egal ob bedingt oder absolut)
}

LCD()
{
LCD Befehle...
return(); --> muss sein damit ich in loop wieder lande.
}

den return brauchst, weil sonst irgendwelche dubiosen Sachen passieren.
Und das ist einfach nur Unsinn.
Lern doch bitte erst mal deine Programmiersprache richtig, ehe du dich 
mit mir anlegst.
Ich diskutier doch auch nicht mit den Jungs von der BMW 
Motorenentwicklung darüber ob der Spalt in den Diesel-Vorglühkerzen(!) 4 
oder 5 hunderstel Millimeter groß sein muss und wundere mich dann 
darüber, dass mir die den Vogel zeigen.

Karl Heinz Buchegger schrieb:
> Frank Frank schrieb:
>> Karl Heinz Buchegger schrieb:
>>> Wo siehst du hier in der Doku, dass in loop eine while Schleife
>>> stattfindet?
>>
>> Hier z.B.: http://arduino.cc/en/Tutorial/WhileLoop
>
> ACh geh bitte, Frank.
>
> Da gehts doch um ganz was anderes.

> Steht doch auch in dem von dir verlinkten Beispiel: solange die Schleife
> läuft, geht nichts anderes mehr.
> Nicht alles was hinkt, ist auch ein Argument.

Du hast ja recht in allem was du sagst, es war nur der Hinweis, dass es 
generell nicht "verboten" ist.

Frank Frank schrieb:

> Du hast ja recht in allem was du sagst, es war nur der Hinweis, dass es
> generell nicht "verboten" ist.


Ja ... wenn einem der Zusatz '... geht nichts anderes mehr ...' egal ist 
oder man das sogar genau so haben möchte.

verboten ist grundsätzlich in der Programmierung überhaupt nichts. Ich 
kann durch 0 dividieren soviel ich lustig bin. Mein Programm wird zwar 
nicht das tun, was ich eigentlich will, aber niemand kann mich daran 
hindern es zu tun. Und schon gar nicht der Compiler.

Karl Heinz Buchegger schrieb:
> Frank Frank schrieb:
>
>> Du hast ja recht in allem was du sagst, es war nur der Hinweis, dass es
>> generell nicht "verboten" ist.
>
>
> Ja ... wenn einem der Zusatz '... geht nichts anderes mehr ...' egal
> ist oder man das sogar genau so haben möchte.
>
> verboten ist grundsätzlich in der Programmierung überhaupt nichts. Ich
> kann durch 0 dividieren soviel ich lustig bin. Mein Programm wird zwar
> nicht das tun, was ich eigentlich will, aber niemand kann mich daran
> hindern es zu tun. Und schon gar nicht der Compiler.

Karl Heinz,

auf Arduino.cc gibt es genau die Hinweise und Warnungen, die du hier 
beschrieben hast. Der Vergleich mit der "Null" ist gut.

Soll er erstmal Beispiel abschreiben, verändern und dann sieht er wie 
das funktioniert.

Verwirrter Anfänger schrieb:

> Der Code wird also nach kleinen Anpassungen an avr-g++ weitergeleitet.
> Und da sich avr-g++ ganz gut an die Sprachstandards hält, verhalten sich
> Funktionen auch genauso wie in allen anderen C++ Programmen.

Genau.
Das in diesem Text immer von C/C++ als Sprache die Rede ist, schreibe 
ich der 'Vorsicht der Dokuschreiber' zu, die verhindern wollen, dass die 
Leute gleich mal beim Lesen von C++ die Hände über dem Kopf 
zusammenschlagen.
Eine Sprache C/C++ gibt es nicht. Es gibt C und es gibt C++. Bis auf 
einige Ausnahmen ist gültiges C auch gültiges C++, so dass viele Leute 
immer das Gefühl haben, man könne beides so gesehen in einen Topf 
werfen. Aber streng genommen stimmt das nicht - was allerdings für 95% 
aller C-Programmierer ziemlich irrelevant sein dürfte. Die Dinge, die in 
C++ - 'Subset' (nicht wörtlich nehmen) anders sind als in echtem C, sind 
entweder schnell angepasst, oder sowieso verpönt.

EGS schrieb:
> Ich habe nur gesagt, dass das "void loop(){..} das dem Main aus anderen
> Compilern gleichzusetzen ist.

Und das ist falsch.

> Wenn ich aber eine weitere Programmroutine aufrufe
> führe ich einen Sprung im Programmcode aus an die Speicheradresse des
> Programmes in dem die betrefenden Anweisungen hinterlegt sind. Wenn ich
> dann nicht explizit sage ich will an der Quelleadresse des Sprunges mit
> der Programmabarbeitung fortfahren, werden die Programmteile des main
> nicht weiter abgearbeitet außer ich komme wieder an eine Stelle, die
> mich mittels Sprungbefehls wieder in den main/loop zurückführt.

Das ist völliger Blödsinn. Eine Funktion springt automatisch an die 
Stelle ihres Aufrufs zurück, wenn sie ans Ende gelangt. Sie fängt nicht 
wieder von vorne an oder führt irgendwelchen anderen Programmcode aus.

> Und mein while(state = 1) sollte ihm bloss sagen, das er den Ton bloss
> erzeugen soll wenn sein Ausgangspin aktiv ist. ich hätte ihm da auch
> nen:
>
> if(state = 1)
> {..}
>
> oder
>
> switch(state)
> case 1{
> ...}
> case 0{
> ...} empfehlen können.
>
> Es ist aber egal, welchen ich davon empfehle

Nein. Denn bei einem while wird die loop()-Funktion nicht verlassen und 
die Arduino-internen Funktionen kommen nicht zum Zug.

> Also Karl Heinz, es geht nicht darum ob die IDE C oder C++ benutzt, da
> stimme ich dir ja zu. Es ging darum, das du mir unterstellt hast, dass
> ich mit dem:
>
> while(state = 1);{... ne Endlosschleife starten wollte.
>

while(state = 1); IST eine Endlosschleife!

EGS wir drehen uns im Kreis

Auf der einen Seite willst du in einer Programmiersprache programmieren, 
auf der anderen Seite lehnst du es ab, die Regeln der Sprache zu 
akzeptieren.

Was soll das?

> Ich habe nur gesagt, dass das "void loop(){..} das dem Main aus
> anderen Compilern gleichzusetzen ist.

Nein.
Es ist dem inneren (markiertem) Teil von

int main()
{
  ...

  while( 1 ) {

    irgendwas

    >>>>>> hier kommt der Inhalt von loop()   <<<<<<
  }
}

gleichzusetzen!
Über den Rest dieses, vom Framework vorgegeben, main() hast du keine 
Kontrolle. Also mach auch keine Annahmen drüber.

> Es ist aber egal, welchen ich davon empfehle, denn in der
> Mmemonik werden die Befehle in Sprungbefehlen
> (rjmp, spb, spa, jmp,...) umgewandelt und an der Zieladresse
> Register und Akku-Operationen hinterlegt.
> Und das hat nix mit C/C++ zu tun.

Richtig. Das hat nicht das geringste mit C bzw. C++ zu tun.
Warum führst du es dann an?

EGS schrieb:
> Wenn ich nen while einbinde, wird in Mmemonik darasus >>springe bedingt
> zu Adresse<<. Und wenn du du mal in das Datenblatt der Atmels schauen
> würdest und nicht von den Compiler ausgehst die du in C oder C++
> fütterst würdest du sehen, wieviele "ret" (= return, die Quell-Adresse
> wird im Adressregister hinterlegt) ein Mmemonik-Code enthält.

> Deswegen habe ich ja bereits gesagt, die Funktion muss dieses return
> bereits enthalten, ansonsten muss ich selber dafür sorgen das es
> vorhanden ist.

Es geht hier um die Programmierung des Arduinos in C++. Dazu muss man 
überhaupts nichts über den Maschinencode des Prozessors wissen. Sondern 
man muss die Regeln von C++ kennen. Die besagen, dass am Ende einer 
Funktion zurückgesprungen wird. Der Compiler fügt das ret also 
automatisch ein, auch ohne dass man explizit return schreibt.

> Deswegen habe ich ja bereits gesagt, die Funktion muss dieses
> return bereits enthalten,

Das tut sie doch!

Deine Assembler Betrachtungen in allen Ehren. Aber die interessieren 
hier keinen!
Wie die Sprache C++ (oder meinetwegen auch C) funktioniert, definiert 
der Sprachstandard und nicht irgendwelche Assembler-Instruktionen! Es 
ist Aufgabe des Compilers, diejenigen Instruktionen auszuwählen, die dem 
entsprechen, was der Sprachstandard für den von mir niedergeschriebenen 
C-Code vorsieht.

> ansonsten muss ich selber dafür sorgen das es
> vorhanden ist.
Quatsch. Hältst du Compilerbauer wirklich für so blöd, dass sie nicht 
wissen, was am Ende einer Funktion zu tun ist?

Karl Heinz Buchegger schrieb:
>> Deswegen habe ich ja bereits gesagt, die Funktion muss dieses
>> return bereits enthalten,
>
> Das tut sie doch!
>
> Deine Assembler Betrachtungen in allen Ehren. Aber die interessieren
> hier keinen!
> Wie die Sprache C++ (oder meinetwegen auch C) funktioniert, definiert
> der Sprachstandard und nicht irgendwelche Assembler-Instruktionen! Es
> ist Aufgabe des Compilers, diejenigen Instruktionen auszuwählen, die dem
> entsprechen, was der Sprachstandard für den von mir niedergeschriebenen
> C-Code vorsieht.

und ich vergaß dazuzuschreiben (wenn schon, dann wollen wir auch genau 
sein):

... und zwar so, dass sich dadurch die vom Sprachstandard geforderte 
Funktionalität ergibt.

Langer Rede kurzer Sinn:
Als Programmierer orientiere ich mich daran, was mir der Sprachstandard 
garantiert und welche Funktionalität er mir garantiert.
Wie das dann auf Op-Code Ebene realisiert wird, ist Aufgabe des 
Compilers und hat mich zuallererst mal nicht zu interessieren.

EGS schrieb:

> Das das Void loop nicht genau dem main entspricht ist mir klar, ich habe
> bloss einen Ausdruck ("gleichzusetzen") benutzt, der nicht auch
> "ebenbürtig" oder "genau das selbe" bedeutet.

Dein Problem ist, dass du dich eigentlich in fast allem höchst ungenau 
ausdrückst. Genauer gesagt, drückst du dich sehr oft sehr schwammig aus 
und versuchst dich dann hinterher wieder herauszuwinden.

> In der Arduino IDE ist das

Die IDE interessiert schon mal überhaupt keinen.
IDE = Integrated Development Environment
Das ist also einfach die Entwicklungsumgebung.
 Projektverwaltung, Editor, Compiler, Linker

> void loop halt das main der AVR-Studios, darauf soll es hinauslaufen.

und als wie 'ungenau' soll ich jetzt diese Aussage wieder auffassen?
Zum 10-ten mal: Nein. Diese angedeutete 'Entsprechung' ist nicht 
zulässig.

loop() entspricht einem Teil des main() aus der Nicht-Arduino Welt. Aber 
ein Teil ist nicht das Ganze.

Mehr Präzission, wo es notwendig ist!

Und, ach ja:

> Weil deine Compiler aus diesen C oder C++ Codeabschnitten einen
> vom Interpreter verständlichen Code formt

Einen Interpreter gibt es schon mal gar nicht.
Es sei denn, du betrachtest die Befehlsdekodierung und Ausführung 
innerhalb der CPU als 'Interpreter' - was allerdings eine eher unübliche 
Sicht der Dinge ist. Unter einem Interpreter versteht man in der 
Informatik was anderes, selbst wenn man die in Silizium gegossene Logik 
in weitesten Sinne auch als eine Art Interpreter, realisiert durch 
Mikrocode, bezeichnen könnte.

EGS schrieb:
> Karl Heinz Buchegger schrieb:
>> Quatsch. Hältst du Compilerbauer wirklich für so blöd, dass sie nicht
>>
>> wissen, was am Ende einer Funktion zu tun ist?
>
> Eigene Funktionen schreiben und nen *.h-File daraus erstellen, dann
> musst du dies selber vorsehen.

Was für ein Unsinn.


> PS: wenn du dann auch noch beruflich dich mit Step7 AWL-Programmen
> auseinandersetzen darfst wirst du merken das dir C da nicht mehr
> weiterhilft, AWL ist hardwarenahe Programmierung, weil bereits in
> MMemonik. Da schreibst du deine Funktionen selber. Hier vergisst du nur
> einmal den bedingten oder absoluten rücksprung, ansonsten vergisst du
> einen Zykluss lang nen ganzen Programmteil, was dann schnell mal richtig
> Geld kostet.

Hier geht es aber nicht um AWL oder Step7
Hier geht es um C++ bzw. C

Ich kann nur hoffen, dass du dich in AWL besser auskennst als in C. Denn 
sonst hast du mit "richtig Geld kostet" voll ins Schwarze getroffen.

Ich kenn mich mit AWL nicht aus, daher melde ich mich auch nicht zu 
Wort, wenn es darum geht. Aber mit C kenn ich mich richtig gut aus und 
daher sag ich dir ... du erzählst hier C-Neulingen Unsinn.

EGS schrieb:
> In der Arduino IDE ist das
> void loop halt das main der AVR-Studios, darauf soll es hinauslaufen.

Der Satz wird durch Wiederholen nicht korrekter. Erstens hat das nichts 
mit den IDEs zu tun und zweitens ist es schlichtweg falsch. Die 
main()-Funktion in C/C++ wird nur ein einziges Mal zu Beginn des 
Programms aufgerufen. Die loop()-Funktion wird dagegen vom 
Arduino-Framework in einer Endlosschleife wiederholt aufgerufen. So 
gesehen ist die setup()-Funktion der main()-Funktion ähnlicher als 
loop().

Aber was bringen solche schwammigen Aussagen? Außer Verwirrung von 
Anfängern tragen sie nichts zum Thema bei. Wenn man mit dem 
Arduino-Framework programmiert muss man die Funktionen so benutzen wie 
vorgesehen. Dazu gehört, dass man in loop() nicht selber eine 
Endlosschleife definiert.

EGS schrieb:
> Karl Heinz Buchegger schrieb:
>> Die IDE interessiert schon mal überhaupt keinen.
>>
>> IDE = Integrated Development Environment
>>
>> Das ist also einfach die Entwicklungsumgebung.
>>
>>  Projektverwaltung, Editor, Compiler, Linker
>
> An der hast du dich hochgezogen, da lass ich mir das Wort im Munde nicht
> umdrehen.

Ich hab mich an der IDE hochgezogen?
Wo genau?

Kann natürlich sein, dass ich mich mal vertippt habe. Aber ansonsten hab 
ich ständig auf das Framework verwiesen.
Framework  !=   IDE



> main ist auch nicht das ganze. Da die Hauptfunktion des loop und des
> main aber eine dauerhaft immer wieder abgearbeitete Programmstruktur
> enthält sogesehen das gleiche machen. aus dem loop heraus rufen die
> Funktionen die anderen inkludierten Programmfunktionen auf, die du
> entweder im main bei dir hast oder auch über "#include lcd.h" bei dir
> hast. Dein main ist auch nicht alles.

Selbst wenn ich ein Auge zudrücke, enthält dieser Absatz schon wieder so 
viele Dinge, die auf ein Nichtverstehen der tatsächlichen Sachlage 
schliessen lassen, dass ich mir das jetzt einfach mal spare darauf 
einzugehen.

Karl Heinz Buchegger schrieb:

> Selbst wenn ich ein Auge zudrücke, enthält dieser Absatz schon wieder so
> viele Dinge, die auf ein Nichtverstehen der tatsächlichen Sachlage
> schliessen lassen,


Entweder das, oder du verwendest die Wörter tatsächlich in einer eigenen 
Bedeutung, die du anlassbezogen gerade erfindest, wenn du die Wörter 
benutzt.
In diesem Falle ist jegliche weitere Diskussion sinnlos - obwohl ich 
sowieso der Meinung bin, dass sie sinnlos ist. Nur sollten spätere Leser 
nicht auf eine falsche Fährte gelockt werden.

EGS schrieb:
> main ist auch nicht das ganze. [...]

EGS, wenn man Dir zuhört, ist das genauso wie einem Blinden zuzuhören, 
der von Farben redet. Hör einfach auf damit. Du erzählst nur halbe 
Wahrheiten, die niemandem helfen.

EGS schrieb:
> Fallobst schrieb:
>> PS: Es gibt hier keinen Interpreter!
>
> http://www.elektronik-kompendium.de/sites/com/1705231.htm
>
> Wenn der Compiler es aber nicht richtig macht, muss man entweder selber
> wissen was los ist oder wartet aufs update vom Entwickler des
> Compilers...

Wenn ein Compiler DIESES Detail nicht richtig macht, kommt er erst gar 
nicht von der Entwicklungsmaschine runter!

Du scheinst wirklich Compilerbauer für komplett unfähige Vollidioten zu 
halten. Denkst du wirklich ein Compiler muss nicht erstmal sich durch 
eine Testuite durchackern, ehe er auf das breite Publikum losgelassen 
wird?

Das ein Compiler schon mal Fehler enthalten kann, streitet keiner ab. 
Aber es gibt Fehler, die fallen SOFORT beim allerersten Testlauf auf.
Und da die meisten Compiler in ihrer eigenen Sprache geschrieben sind 
(ein C-Compiler ist in C geschrieben), ist das erste nichttriviale 
Testprogramm sein eigener Source-Code. Der Compiler übersetzt sich also 
einmal selbst. Da kriegt man einen A-Compiler raus. Dieser A-Compiler 
muss nochmal seinen eigenen Code übersetzen. Man kriegt einen 
B-Compiler. A-Compiler und B-Compiler müssen Byte für Byte identisch 
sein, sonst verlässt diese Compilerversion die Entwicklungsmaschine 
nicht.

Was denkst du, wieviele Compilerfehler, bei denen ein wesentliches 
Grundfeature falsch behandelt wird, es durch diesen Prozess schaffen?

spess53 schrieb:
> Hi
>
>>while(state = 1); IST eine Endlosschleife!
>
> Nicht unbedingt. 'state' kann immer noch in einer Interruptroutine
> verändert werden. Und dann ist es eine Endlichschleife.
>
> MfG Spess

Ich gebe ja zu, dass ich das nicht im Blick hatte. Trotzdem bleibt meine 
Aussage richtig.
state wird hier überhaupt nicht ausgewertet, sondern auf 1 gesetzt.
Und diese Zuweisung ergibt immer !=0, also wahr, also Endlosschleife.

EGS schrieb:

> Klar durchläuft es Testreihen, aber selbst wenn, sind da eben auch noch
> Fehler drinen, [...]

Ich empfehle Dir: Verlasse Dein Haus nie mehr. Setz Dich irgendwo still 
in eine Ecke, schalte das Licht und Deinen Rechner aus und warte einfach 
die nächsten Jahre ab, was passiert.

Du redest Dich hier um Kopf und Kragen. Wenn Du tatsächlich Recht 
hättest, dürftest Du keiner Elektronik um Dich herum mehr trauen und Du 
wärest bestimmt schon 50mal in Deinem Leben von einer tollwütig 
gewordenen Straßenbahn überfahren worden.

Du schwafelst ein Zeug... das geht auf keine Kuhhaut. Allein schon Dein 
altklug erscheinender Versuch, Karl Heinz die C-Welt (Compiler & Co) zu 
erklären, entpuppt sich für jeden, der bereits mehr als 2 Postings von 
Karl Heinz gelesen hat, als absolut lächerlich.

Wenn man keine Ahnung hat, einfach mal die Fresse halten.

EGS schrieb:

>> Du scheinst wirklich Compilerbauer für komplett unfähige Vollidioten zu
>>
>> halten. Denkst du wirklich ein Compiler muss nicht erstmal sich durch
>>
>> eine Testuite durchackern, ehe er auf das breite Publikum losgelassen
>>
>> wird?
>
> Denke ich nicht, unterstelle anderen nicht immer deinen Gedanken.
> (Sorry, ist aber so).

Das muss ich aber annehmen, wenn von dir die Behauptung kommt, dass 
Compiler keinen automatischen Return in eine Funktion einbauen können, 
wenn die in einem anderen Source Code File steckt.

> sind da eben auch noch
> Fehler drinen, die in bestimmten Konstellationen auftreten können.
> Man kann nicht jeden Fehler abfangen und berücksichtigen

Oh. Das auch ein Compiler Fehler hat gestehe ich dir gerne zu. Aber das 
er auf ein Return am Ende einer Funktion vergisst, das gestehe ich dir 
nicht zu. Wenn das passieren würde (was in einer Entwicklerversion schon 
sein kann), dann fällt das beim allerersten Testprogramm, welches durch 
den Compiler gejagt wird sofort auf. Spätestens wenn ein Compiler sich 
selbst übersetzt, fallen die meisten Compilerfehler auf. Denn ein 
Compiler ist ein nichttriviales Programm, welches aus einigen hundert 
Funktionen besteht und sich über mindestens 20 verschiedene Source Code 
Files hinzieht, so dass jeder Fehler an dieser Stelle sofort ein 
abstürzendes Programm ergibt. Übersetzt ein Compiler also sich selbst 
und ist das Ergebnis abstürzender Compiler, dann hat man mit Sicherheit 
etwas verbockt. Ist das Ergebnis aber ein lauffähiger Compiler, dann 
kann man mit einer gewissen Sicherheit davon ausgehen, dass zumindest 
díe C-Basiskonstrukte mit einiger Sicherheit fehlerfrei sind. Ein vom 
Compiler vergessener Return am Ende einer Funktion würde hier mit 
Sicherheit sofort auffallen.

> Mmemonikbefehle schneller arbeiten. Also kann der Code aus dem neuen
> Compiler nicht mit dem vorherigen verglichen werden.

Du hast den Bootstrap-Prozess im Compilerbau nicht verstanden.
Hätte mich auch gewundert, wenn du es verstanden hättest.


> C++ Programme. Ich kann Windows und Linux nicht direkt mit dem BIOS
> vergleichen (beispielhaft), da läuft die ganze Diskussion aber grade
> hin.

:-)
Und wenn man in der Ecke steht, macht man flugs ein neues Thema auf und 
versucht den anderen den Themenwechsel in die Schuhe zu schieben.

Das Thema ist immer noch:
C++ auf einem Arduino
Was sichert mir die Sprache zu, was sichert sie mir nicht zu.

Bisher sind von dir nur Behauptungen gekommen, dass du Dinge machen 
musst, die
a) durch nichts belegt sind
b) von denen explizit im Sprachstandard steht, dass du sie eben genau
   nicht machen musst

und wischi-waschi Aussagen, die du nach der 5-ten Urgenz dann doch 
vielleicht eventuell in die richtige Richtung verstanden haben willst, 
weil du dich absichtlich 'etwas schwammig' ausgedrückt hast.


> Da brauche ich keine Angst zu haben, da rede ich mich nicht
> um Kopf und Kragen.

Da hast du recht. Also die Sache mit der Angst haben.
Denn um Kopf und Kragen hast du dich schon längst geredet.


Egal. Ich denke die eigentliche Ausgangssituation ist ausreichend klar 
gestellt worden, so dass auch ein Leser in nächster Zukunft erkennen 
kann, wie die Dinge wirklich sind.

EGS schrieb:
> Karl Heinz Buchegger schrieb:
>> Das muss ich aber annehmen, wenn von dir die Behauptung kommt, dass
>>
>> Compiler keinen automatischen Return in eine Funktion einbauen können,
>>
>> wenn die in einem anderen Source Code File steckt.
>
> Also nocheinmal, anscheinend kann/konnte die Arduino IDE das nicht. Denn
> die Abfrage des LM75 in meinem Beispiel ist nicht wieder aus dem
> Unteraufruf in das loop zurückgekehrt. Erst als ich das besagte Return
> eingefügt hatte.


Und das kommt dir nicht irgendwie komisch vor, dass scheinbar ausser dir 
niemand diese Probleme hat?

Dein Selbstvertrauen möchte ich haben.

EGS schrieb:
> Also nocheinmal, anscheinend kann/konnte die Arduino IDE das nicht.

Verwische hier nicht immer die Begriffe. Eine IDE ist ein besserer 
Editor, sonst gar nix. Was hat das mit dem Compiler zu tun?

> Denn
> die Abfrage des LM75 in meinem Beispiel ist nicht wieder aus dem
> Unteraufruf in das loop zurückgekehrt. Erst als ich das besagte Return
> eingefügt hatte.

Am Ende der Funktion? Das glaube ich nicht. Du hattest vermutlich eher 
am Ende von Loop noch zusätzlich eine Endlosschleife drin, die Du 
nachträglich durch ein vorangestelltes return-Statement unwirksam 
gemacht hast. Ergo hast Du wohl eher einen Fehler in Deinem Programm 
überdeckt...

> Selbiges betraf das LCD, Werte wurden korrekt angezeigt, aber die
> Programmschleife hing in den Unterprogrammen fest. Nur noch die
> Drehencoder Werte wurden mittels Interupt erfasst. Komisch ist dass es
> halt so funktionierte, ich hatte keine while-Schleifen verwendet,
> sondern klassisch if und switch case.

Du hättest Dich mit Deinem Arduino 3 mal nach Mekka verneigen sollen, 
dann hätte es bestimmt auch geklappt. Hör auf zu schwafeln und zeig 
Deinen Code, dann sag ich Dir auch, wo Deine Fehler stecken.

> http://arduino.cc/en/Reference/Return

Ja und? Du hast keine Ahnung von dem, was Du da verzapfst.

Frank M. schrieb:

> Du hättest Dich mit Deinem Arduino 3 mal nach Mekka verneigen sollen,
> dann hätte es bestimmt auch geklappt.

Weils grade so schön passt

http://c2.com/cgi/wiki?VoodooChickenCoding

Interessiert sich eigentlich noch irgend jemand für die Ausgangsfrage?

Für mich ist zumindest klar, dass ich den Entschluss, ganz schnell von 
Arduino weg zu gehen und C zu lernen, sicher nicht bedauern werde.

Gerade Karl Heinz hat mir schon so nützliche Tipps gegeben (@Karl Heinz: 
manchmal auch indirekt, indem ich deine Texte anderen zu Hilfe las).

Arduino soll so einfach sein und tatsächlich hatte ich nach drei Monaten 
ein erstes Projekt fertig. Mit One-Wire, PWM und ...
Wäre sicher nicht so schnell gegangen, wenn ich anders angefangen hätte.
Aber mit Arduino, mag sein, dass es doch geht, sprich mal einen ganzen 
Port an! Ich hatte da ganz gewaltige Schwierigkeiten den Kodierschalter 
zum laufen zu bekommen. In C ein Klacks.

Im Moment lerne ich zwar wieder mehr Basics und insbesondere über 
Stromversorgung, aber C (später auch C++) haben doch wesentlich mehr 
Aussicht auf langfristigen Erfolg. Arduino ist eine Sackgasse.

Aber vielleicht helft ihr jetzt mal wieder dem Threadsteller bei seinem 
Problem!

Frank Frank schrieb:
> Interessiert sich eigentlich noch irgend jemand für die Ausgangsfrage?


Was war das?
Ach ja, die Frage nach dem tone().

Lässt sich auf 2 Arten beantworten
  tone kann man auch auf Dauerton stellen
  oder eben in loop() nach jeweils einer bestimmten Zeit wieder
  neu starten.

So wie er es gemacht hat, ist der Aufbau nicht sehr schlau und ich sehe 
grade, dass unter anderem eines der Probleme darin besteht, dass er am 
Ende von loop() eine Endlosschleife eingebaut hat.


> Wäre sicher nicht so schnell gegangen, wenn ich anders angefangen hätte.
> Aber mit Arduino, mag sein, dass es doch geht, sprich mal einen ganzen
> Port an!

Doch das geht.
Nur weil du vom Framework Funktionen und Klassen bereit gestellt 
bekommst, bedeutet das ja nicht, das alles andere still gelegt wurde. 
D.h. Portzugriffe funktionieren auch in diesem Framework genau so, wie 
wir das hier ohne Framework auch machen. Prinzipiell ist das alles 
komplett gleich (Kunststück, liegt ja auch derselbe Compiler mit 
denselben AVR-Header Files drunter)

Wenn du also setup() und loop() in diesem Zusammenhang siehst

int main()
{
  xxxx
  setup();
  xxxx

  sei();

  while( 1 ) {
    xxxx
    loop();
    xxxx
  }
}

wobei xxxx Codeteile markiert, die einfach da sind und die du nicht 
beeinflussen kannst, dann programmierst du im Grunde auch nicht soo viel 
anders, als wir hier.
Einzig aufpassen muss man, weil ja das Arduino Framework sich einige 
Dinge für sich selber reserviert (ich denke mal Timer werden die 
prominentesten derartige Kondidaten sein). D.h. die sind für dich 
insofern tabu, als du nicht mit direkter Register-Manipulation drann 
gehen solltest.

> Aussicht auf langfristigen Erfolg. Arduino ist eine Sackgasse.

Man muss immer im Hinterkopf behalten, was die Idee am Arduino war. Die 
Idee war es nicht, dem Crack, der auch noch das letzte Bit beim Vornamen 
kennen möchte, ein Werkzeug in die Hand zu geben.

> Aber vielleicht helft ihr jetzt mal wieder dem Threadsteller bei seinem
> Problem!

Ist gar nicht mal so einfach, weil zumindest für mich nicht so ganz 
ersichtlich ist, wo die Reise überhaupt hingehen soll.

Ein ....

void loop()
{
  tone(13, 5500);
}

... erfüllt im Grunde seine Vorgabe schon - Dauerton.
Was er da mit dem Interrupt vor hat, kann ich zwar ungefähr erraten, 
macht aber für mich eher wenig Sinn.

Karl Heinz Buchegger schrieb:


> Ein ....
>

> void loop()
> {
>   tone(13, 5500);
> }
> 

>
> ... erfüllt im Grunde seine Vorgabe schon - Dauerton.

Das war natürlich kompletter Blödsinn.
EGS hat schneller kapiert, was das Ziel der Übung war.

Eine andere Lösung könnte zb so aussehen

void setup()
{
  pinMode(13, OUTPUT);
  attachInterrupt(0, blink, FALLING);
}

void loop()
{
}

void blink()
{
   tone(13, 5500, 5000);
}

EGS schrieb:

> Ich hätte es eher so gedeutet, das er hier durch den Interup getriggert
> den Ton erst erzeugen will und mit einem erneuten Wechsel des Zustands
> am Interuptpin diesen wieder beendet.

Ja, habs erst gemerkt, als ich mal gegoogelt habe, was attachInterrupt 
eigentlich macht :-)

Ich bin vorher von irgendeiner Timer Situation ausgegangen, wodurch die 
Tondauer von 5.5 Sekunden keinen Sinn mehr gemacht hat.

Mein Fehler. Ich hätte erst googlen sollen und dann schreiben.

> Sowas wie nen Alarmton, der bei
> Beendigung der Alarmsituation wieder ausgeht.

Zum Bleistift.
Wie eine Lösung genau aussehen soll, kann man erst sagen, wenn man weiß, 
wie Michael sich das Zusammenspiel aus Pin und Tröte vorstellt.

Das wäre für mich ein Fall für den Vorschlaghammer, aber jeder wie er 
mag und ich bin sicher, das war auch nur ein Testprogramm :-)

Karl Heinz Buchegger schrieb:
> ... erfüllt im Grunde seine Vorgabe schon - Dauerton.
> Was er da mit dem Interrupt vor hat, kann ich zwar ungefähr erraten,
> macht aber für mich eher wenig Sinn.

Hab ich auch nicht verstanden.

Ich hatte verschiedene Bücher zu Arduino hier, im Netz gegooglet und 
hatte nichts dazu gefunden. Erst jetzt weiß ich, dass ich da auch C oder 
C++ einbauen kann.
Aber wenn man das dann schon weiß und man weiß wie es in C geht, dann 
brauche ich das doch gar nicht mehr.

Die Syntax von Arduino gab da anfangs nichts zu her und ich hatte mir 
dann eine eigene Lösung gestrickt.

Hatte damals mit Visual Basic, die allererste Version, angefangen. War 
relativ teuer. Damals über 400 DM und nach einigen anfänglichen 
Versuchen mit den Lernvorgaben, wollte ich was Eigenes machen. Da kam 
dann immer der Hinweis, "geht nur mit dem SDK", welches dann noch mal 
mit über 700 Euro zu Buche geschlagen hätte.
So ähnlich sehe ich Arduino auf der Softwareseite. Will ich 
ausschließlich den Funktionsumfang von Arduino nutzen, dann gehen einige 
Sachen nur schwer bis gar nicht.
Wobei ich die Boards ganz toll finde. Insbesondere den Nano fürs 
Steckbrett.

Fallobst schrieb:
> Die Variable state ist
> hier nutzlos - schau dir das nochmal an.

Genau wie die Warteschleife in loop(). Was reden wir denn schon seit 80 
Beiträgen ...

Michael schrieb:
> Habe das Programm jetzt nochmal geschrieben! Es funktioniert auch!
> Einzigstes Manko ich kann den Interrupt nur zweimal ganz schnell
> hintereinander auslösen, danach funktioniert es nicht mehr! Warum???
Der Grund steht in der Dokumentation zu "tone()".

Only one tone can be generated at a time. If a tone is already playing on a different pin, the call to tone() will have no effect. If the tone is playing on the same pin, the call will set its frequency.

Du musst warten bis der Tone geendet hat oder Du schaltest den Tone 
manuell EIN und AUS.

void loop()
{
  if( state )
  {
    tone(13, 5500);
  }
  else
  {
    noTone(13);
  }
}

void blink()
{
  state = !state;
}

Und lass bitte die Endlosschleife in "loop()" weg.

EGS schrieb:

> PS: wenn du dann auch noch beruflich dich mit Step7 AWL-Programmen
> auseinandersetzen darfst wirst du merken das dir C da nicht mehr
> weiterhilft, AWL ist hardwarenahe Programmierung, weil bereits in
> MMemonik. Da schreibst du deine Funktionen selber. Hier vergisst du nur
> einmal den bedingten oder absoluten rücksprung, ansonsten vergisst du
> einen Zykluss lang nen ganzen Programmteil, was dann schnell mal richtig
> Geld kostet.

P.S.:

Das zeigt MIR das du von nichts richtig Ahnung hast, und zwar ne ganze 
Menge. AWL ist mitnichten Hardwarenah, die Struktur ist nur 
Assemblerähnlich, das wars auch schon. Ausserdem ist AWL seit Jahren auf 
dem absteigenden Ast. Und wenn DIR deine, sowieso sehr lückenhaften und 
teilweise falschen, C Kenntnisse auf der S7 nicht weiterhelfen, ist das 
dein Problem, denn heutzutage programmiert man S7 eher in ST/SCL (was 
syntaktisch Pascal ähnelt) oder mittlerweile sogar, oh Wunder, in C ...

Ich trolle ungern, aber DU hast von nichts richtig Ahnung, vermischt 
Sachen die nichts miteinander zu tun haben und hälst dich nicht an 
Regeln die dir ein System vorgibt. Ich hoffe nur du programmierst nichts 
was mal in den Handel kommt, denn dann kannst mit dem teuer werden in 
der Tat recht haben.