Interrupt Probleme beim Arduino

[Michael (Gast)]

Hallo zusammen,

ich möchte das nachfolgende Programm immer wieder durch einen Interrupt 
starten bzw das Programm soll durch eine andere PWM gestartet werden!
Da ich noch ein Blutiger Anfänger bin weiß ich nicht was ich falsch 
mache!
Danke schon mal für eure Hilfe im Vorraus!

Hier das Programm:


volatile int state = LOW;


void setup()
{

  pinMode(13, OUTPUT);
  attachInterrupt(0, blink, CHANGE);

}

void loop()
{
  -->muss ich hier noch eine while() einsetzen dass, das Programm 
unendlich
  läuft?

  tone(13, 5500, 5000);
  while(true) {}
}

void blink()
{
  state = !state;
}

[Markus M. (mark_m)]

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

[Karl H. (kbuchegg)]

> 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 (Gast)]

Moin,

Ich würd dir empfehlen auf eine bestimmte Flanke des Interup-Inputs zu 
reagieren, z.B. auf die steigende.

volatile int state = LOW;


void setup()
{

  pinMode(13, OUTPUT);
  attachInterrupt(0, blink, Rising);

}

void loop() --> Dauerernde Abarbeitung
{

while(state = true) {
tone(13, 5500, 5000);
}

}

void blink() -->Interuptroutine
{
  state = !state;

}

Bei jeder Änderung des Interuptpins wird ja dein Interupt ausgelöst. 
Wenn du da nun noch Schwankungen/nicht entprellte Signale dran hast, 
wird "blink" jedesmal ausgeführt und somit dann auch Tone neu gestartet.

Zusätzlich muss dein Ton, wenn es nur in dem Fall, dass deine LED ein 
ist auch einen Ton geben soll in die While-Schleife...siehe oben.

MfG EGS

[EGS (Gast)]

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, sogesehen das 
"main" aus anderer C-Programmierung.

Wenn er keinen Interupt verwendet und mittels des Aufrufs:

tone();

dann

"void tone()

{
Programmtext...
return();
}"

aufruft, muss am ende von tone dann noch ein return(); angefügt werden, 
damit er wieder in loop landet. Für die Tone-Funktion ist dies aber 
großer Mist, weil dann auch die Tonerzeugung abbricht.

Hatte am Anfang auch Probleme, das er mir aus Unterprogrammen nicht 
wieder rauskam, irgendwie bin ich aber dann wieder drauf gekommen, das 
da was fehlen musste...

MfG EGS

[Karl H. (kbuchegg)]

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 (Gast)]

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?

Warum ist das verboten?

[Karl H. (kbuchegg)]

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.

[Fabian O. (xfr)]

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.

[EGS (Gast)]

Karl Heinz Buchegger schrieb:
> Nö.
>
> Auf einem Ardunio arbeitet man so, dass man ein main voraussetzt,
>
> welches so aussieht

Hust, also was die IDE im Hintergrund macht ist jetzt nicht das Thema, 
aber die IDE und Dokumentation sagt unbestreitbar:

loop ist die Hauptschleife des immer abgearbeiteten Programmcodes. Setup 
nur einmal zum µC-Start/Reset.

Da  man auch innerhalb des Void loop ander Routinen aufrufen kann bin 
ich nicht nur an diese struktur gebunden. Wichtig ist nur, dass ich 
wieder dahin zurückkehren muss, wenn ich auf den Aufruf folgende 
Anweisungen auführen möchte.

Bestes Beispiel:

ich rufe in einem Programm im eine LCD-Ansteuerung auf:

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.
}

[Düsendieb (Gast)]

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 und das Programm macht auch was ich 
erwartet habe.

Diese ominösen delay Konstrukte werde ich sowieso nie nutzen.

Axel

[EGS (Gast)]

EGS schrieb:
> loop ist die Hauptschleife des immer abgearbeiteten Programmcodes. Setup
>
> nur einmal zum µC-Start/Reset.

wenn ich aber eine andere Routine aufrufe, wird das Hauptprogramm 
natürlich hier unterbrochen, bis ich an die Stelle zurückspringe.

Das ist bei euch auch so ohne die Arduino IDE.

Eigentlich sind es alles nur wahr oder falsch vergleiche die dann 
bedingte oder absolute Sprünge ausführen. Die IDE macht aus "LCD(); nur 
den aufruf eines Bestimmten Programmspeicherbereiches.

[Karl H. (kbuchegg)]

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.

[Fabian O. (xfr)]

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 (Gast)]

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 und das Programm macht auch was ich
> erwartet habe.
>
> Diese ominösen delay Konstrukte werde ich sowieso nie nutzen.
>
> Axel

Die ominösen "delay()" konstrukte sind in den normalen AVR studiosn auch 
drin. Hier heissen diese dann halt "wait()" und im Arduino benutzt man 
den Programmlaufzeittimer wenn man kein Delay haben möchte.

Denn wie der Name delay() oder wait() bereits impleziert wird der 
Prozessor hier zum warten und nixtun verdammt. alle anderen 
Programmteile laufen dann richtigerweise auch nicht weiter.

Ein gutes Beispiel wo dies in Software auch drin ist ist Java. hier kann 
man sein ganzes System mit der Wartefunktion auslasten , obwohl nix 
passiert ;)

MfG EGS

[Düsendieb (Gast)]

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

Hallo Karl Heinz,
mach bitte weiter, soviel fundiertes Wissen und so viel 
Hilfsbereitschaft wie bei Dir ist echt klasse.


Axel

[EGS (Gast)]

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.

Anscheinend war/ist die IDE in diesem Fall darauf angewiesen. Getestet 
mit einem Belichtungstimer der seine Werte auf einerm LCD (Sollzeit, 
Restzeit, Belichtungsstärke und Gehäuseinnentemperatur über einem LM75) 
darstellt.

MfG EGS

[Karl H. (kbuchegg)]

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.

[F. F. (foldi)]

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

[EGS (Gast)]

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. 
Solltest du eigentlich wissen.

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

[Karl H. (kbuchegg)]

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?

[F. F. (foldi)]

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

[EGS (Gast)]

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.

Karl Heinz Buchegger schrieb:
> 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?
>

Weiss nicht was du mir da in den Mund legen willst, aber ich habe nix 
gegenteiliges behauptet. ich sagte nur, dass wenn ich einen Sprung 
ausführe dem Programm sagen muss, dass wieder zurückspringen muss.

Entweder die Funktion die den Sprung auslöst (z.B. delay(); ) macht dies 
von sich aus oder ich muss dafür sorgen, dass ich an der Ausgangsadresse 
im Programmcode wieder mit dem hauptprogramm weitermache. Ansonsten 
arbeite ich den Programmcode ab der auf meine Sprungziel folgt.

Nixc anderes habe ich gesagt, und wenn du denkst das ist Unsinn, bitte.

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

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.

[F. F. (foldi)]

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.

[Karl H. (kbuchegg)]

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.

[F. F. (foldi)]

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 (Gast)]

Karl Heinz Buchegger schrieb
> 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

Um dass nochmal zu erweitern.

Aus dem Arduino FAQ:
> Can I program the Arduino board in C?

>In fact, you already are; the Arduino language is merely a set of C/C++ functions
>that can be called from your code. Your sketch undergoes minor changes (e.g.
>automatic generation of function prototypes) and then is passed directly to a
>C/C++ compiler (avr-g++). All standard C and C++ constructs supported by avr-g++
>should work in Arduino. For more details, see the page on the Arduino build
>process.

(http://arduino.cc/en/Main/FAQ)

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.

[Karl H. (kbuchegg)]

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 (Gast)]

Sorry, Mittagspause...

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.

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

Im void läuft der hauptprogrammcode ab(wie du auch richtig aus der FAQ 
reuszitiert hast). 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.

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, 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.

Und da kannst du nix dran ändern und im C++ noch so viel anders machen 
wollen, das ist der Maschinencode.

[Fabian O. (xfr)]

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.

[EGS (Gast)]

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

? Hab och auch nicht behauptet, aber wie gesagt, das ist der C-Code.

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.

Verwirrter Anfänger schrieb:
> the Arduino language is merely a set of C/C++ functions
>
>>that can be called from your code. Your sketch undergoes minor changes (e.g.
>
>>automatic generation of function prototypes

Funktionen!=Klassen...

[Josef D. (jogedua)]

> 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!

[Karl H. (kbuchegg)]

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?

[Karl H. (kbuchegg)]

> 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.

[Karl H. (kbuchegg)]

> 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?

[spess53 (Gast)]

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

[EGS (Gast)]

Josef D. schrieb:
>> 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!

Nö eben nicht, denn "state" ist eine Variable, die durch die 
Interuptroutine beinflusst wird. Durch dden Befehl "state=!state" wird 
dieser bei auftreten des Interupts negiert, daher ist er nicht immer 
wahr, woraus folgt, das die Programmteile aus der while-Schleife nur bei 
state == 1.

aber ich seh grad ich hab nen "=" vergessen, dann ist es berechtigt. 
Soll natürlich while(state == 1) heißen...t'schuldigung.

MfG EGS

[Fabian O. (xfr)]

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.

[Karl H. (kbuchegg)]

> 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 H. (kbuchegg)]

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 (Gast)]

Karl Heinz Buchegger schrieb:
> Richtig. Das hat nicht das geringste mit C bzw. C++ zu tun.
>
> Warum führst du es dann an?

Weil deine Compiler aus diesen C oder C++ Codeabschnitten einen vom 
Interpreter verständlichen Code formt, und auf diese Arbeistweise muss 
man sich beziehen. Denn hier finden dann die Sprünge statt.

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. In der Arduino IDE ist das 
void loop halt das main der AVR-Studios, darauf soll es hinauslaufen.

EGS schrieb:
> Das ist ja in dieser Umgebung schon die Endlosschleife, sogesehen das
>
> "main" aus anderer C-Programmierung.

[Karl H. (kbuchegg)]

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!

[EGS (Gast)]

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.

Ansonsten ist man auch so nix anderes als die meisten hier immer über 
Arduino-Benutzer meckern. Man benutzt fertige Funktionen (libaries), die 
man ja dann nicht vertsehn muss was in ihnen passiert, nur das drumherum 
interessiert.

Welche Operationen hinter logischen und arithmetischen Operationen im C 
oder C++ stehen sind dann meistens doch ganz gut zu wissen.

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.

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

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.

[Fabian O. (xfr)]

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 (Gast)]

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.

Die schwammige Formulierung des Vergleichs soll ja auch so sein, da Sie 
nicht als ebenbürtig anzusehen sind.

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.

[Fallobst (Gast)]

EGS schrieb:
> Das ist dein Interpreter der daraus den Programmcode compiliert.

EGS schrieb:
> Interpreter verständlichen Code formt

YMMD!

PS: Es gibt hier keinen Interpreter!


EGS schrieb:
> und auf diese Arbeistweise muss
> man sich beziehen. Denn hier finden dann die Sprünge statt.

Das wird der Compiler schon richtig machen. Man muss sich als reiner 
C-Programmierer damit überhaupt nicht auseinandersetzen.

[Karl H. (kbuchegg)]

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 H. (kbuchegg)]

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 (Gast)]

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...

Schöne Sache so kommt die ganze Bananen-Software zustande...

YMMD

[Frank M. (ukw) (Moderator)]

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.

[Karl H. (kbuchegg)]

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?

[Josef D. (jogedua)]

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 (Gast)]

Karl Heinz Buchegger schrieb:
> 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?

Denke ich nicht, unterstelle anderen nicht immer deinen Gedanken.
(Sorry, ist aber so).

Klar durchläuft es Testreihen, aber selbst wenn, sind da eben auch noch 
Fehler drinen, die in bestimmten Konstellationen auftreten können. Man 
kann nicht jeden Fehler abfangen und berücksichtigen, dann wären wir ja 
bei ewigen Entwicklungszeiten und hätten hinterher nicht soviele 
Probleme mit der Technik (bestes Beispliel Intel Chipsätze für Haswell 
haben Probleme mit USB3.0 Geräten nach S3-Standby, erkennen die 
Teilweise nicht mehr, nue Neustart hilft...oh da wird ja alles wieder 
neu initialisiert und auch das ADR zurückgesetzt in den Controllern...).

Und neue Compiler sollen den Code der am Ende rauskommt optimiert haben, 
da sie neue Programmabfolgen berücksichtigen oder über andere 
Mmemonikbefehle schneller arbeiten. Also kann der Code aus dem neuen 
Compiler nicht mit dem vorherigen verglichen werden. Das der Gleiche 
Compiler als Grundlage die selben Ergebnisse liefern muss, ist denke ich 
allen klar.

Da es hier um µCs geht muss man diese betrachten und nicht die SCHEISS 
C++ Programme. Ich kann Windows und Linux nicht direkt mit dem BIOS 
vergleichen (beispielhaft), da läuft die ganze Diskussion aber grade 
hin.

[EGS (Gast)]

Josef D. schrieb:
> 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.

NEEEIIIINN eben nicht, wenn im nächsten Durchlauf die Interuptroutine 
aufgerufen wird, wenn state == 1 dann wird es doch wieder negiert. daher 
ist es dann wieder 0, bis der Interupt wieder ausgelöst wird.

[EGS (Gast)]

Edit: aber nur wenn while(state==1) geschrieben wird, denn state=1 setzt 
den ja auf 1...

[Frank M. (ukw) (Moderator)]

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 (Gast)]

Frank M. schrieb:
> 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.

Zusammenhang? Fehler in Soft- und Hardware liegen beim Entwickler, 
wurden beim Test übersehen und/oder billigend in Kauf genommen, da man 
sie nicht als hochprior zu beheben eingestuft wurden. Gibt es genug 
Beispile für.

Da brauche ich keine Angst zu haben, da rede ich mich nicht um Kopf und 
Kragen. Und ne tollwütige Straßenbahn, mach du dich nicht auch 
lächerlich.

Deine herablassende Art kannst du lassen.

[Karl H. (kbuchegg)]

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 (Gast)]

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.

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.

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

i'm out...

PS: du hast mit C++ angefangen, da brauch ich auch nicht streiten.

[Karl H. (kbuchegg)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Karl H. (kbuchegg)]

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

[EGS (Gast)]

Frank M. schrieb:
> 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...

Glaube ich kaum, die letzten Befehle werden auch sauber ausgeführt. Wenn 
dem so wäre würde ich ja Funkltionen vermissen.

Frank M. schrieb:
> 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?

Verweis auf den verwendeten Befehl, und sorry nicht jeder hat den ganzen 
Tag seinen privaten Rechner um den Hals hängen. Um eventuell mal seinen 
Code posten zu können.

[Electronics'nStuff (Gast)]

Schlagt' euch tot um den Sch*** Arduino-Compiler :)
Die sinnloseste Diskussion, die ich seit langem gelesen habe!

[F. F. (foldi)]

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!

[EGS (Gast)]

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

Sorry hast ja recht, aber dachte dass hatten wir bereits geklärt:

volatile int state = LOW;


void setup()
{

  pinMode(13, OUTPUT);
  attachInterrupt(0, blink, Rising);

}

void loop() --> Dauerernde Abarbeitung
{

while(state == true) { //--> Wichtig hatte hier vorhin auch nur ein "="
tone(13, 5500, 5000);
}

}

void blink() -->Interuptroutine
{
  state = !state;

}

Sind leider abgedriftet...

Wie gesagt alternativ zum while(... auch nen if(...

[Karl H. (kbuchegg)]

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.

[Verwirrter Anfänger (Gast)]

Frank Frank schrieb:
> Arduino ist eine Sackgasse.

Wieso?

Für mich ist ein Arduino eine Auffahrt auf die C / C++ Autobahn.

Das Arduino Framework ist C++ mit einigen zusätzlichen Libraries, einer 
IDE und Entwicklungsboards. Auf einem Arduino kannst du nahezu alles 
machen, was mit Standard AVR-C / AVR-C++ auch geht.

PORTB |= (1 < PB2) | (1 < PB3);

geht auf einem Arduino genauso wie mit dem normalen avr-g++. Das Einzige 
bei dem du aufpassen musst, sind ein paar Interrupts. Der Timer 0 wird 
u.a. für die millis() Funktion belegt, und die Serial Library benutzt 
natürlich die entsprechenenden Interrupts. Aber ansonsten ist nahezu 
alles möglich.

Ich benutz meinen Arduino ganz gerne mal, wenn ich schnell was 
ausprobieren will. Gerade wenn es um Sensoren oder andere Periphery 
geht, für die es schon Libraries gibt. Mal schnell RFID ausprobieren, 
geht doch um einiges einfacher als alles von Hand zu machen. Später kann 
man das dann "ordentlich" machen, aber nur um zu wissen, ob es überhaupt 
funktioniert ist der Arduino meiner Meinung nach gut geeignet.

[Karl H. (kbuchegg)]

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 (Gast)]

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.

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. Sowas wie nen Alarmton, der bei 
Beendigung der Alarmsituation wieder ausgeht.

Dazu brauchen wir aber Input von Michael.

[Karl H. (kbuchegg)]

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

[Fallobst (Gast)]

Verwirrter Anfänger schrieb:
> Aber ansonsten ist nahezu alles möglich.

Gegenbeispiel:
Ein paar meiner Projekte sind recht zeitkritisch. Da darf kein Interrupt 
mal für 100 Zyklen den Programmablauf unterbrechen. Genau das machen die 
Arduino-Libs. Ich habe den µC gerne unter meiner Kontrolle, genauso wie 
den Timer0. Wenn ich einen Millisekundentimer benötige ist der in 30 
Sekunden von Hand(!) programmiert. Allgemein habe ich noch keine Libs 
gesehen, die so verschwenderisch mit Resourcen umgehen, wie diese.

Außerdem bin ich froh, dass ich nicht genötigt werde eine steinzeitliche 
IDE (die sich modern nennt) zu benutzen.

Verwirrter Anfänger schrieb:
> einiges einfacher als alles von Hand zu machen

Hm, das gibts auch ohne Arduino. Einfach 1 Minute gurgeln. Außerdem 
Resourcensparender und mit Sicherheit schneller.

Verwirrter Anfänger schrieb:
> Für mich ist ein Arduino eine Auffahrt auf die C / C++ Autobahn.

Naja, eher Abfahrt in die 30ger-Zone, in der jeder fahren kann.

[EGS (Gast)]

Glaube ich auch, war zwischendurch nen Tee trinken. Dann hab ich mich 
wieder gesammelt.

Bin wohl nen bissel ausgeschlagen ;)

Wollen den Leuten hier doch helfen.

MfG,
der sich auf seinen Feierabend freuende EGS

[EGS (Gast)]

Fallobst schrieb:
> Außerdem bin ich froh, dass ich nicht genötigt werde eine steinzeitliche
>
> IDE (die sich modern nennt) zu benutzen.

Jeder nach seiner Facon, ich steinige auch keinen weil er VW nicht mag 
oder Nissan liebt.

Man muss halt schaun wie man mit zurecht kommt.

Fallobst schrieb:
> Allgemein habe ich noch keine Libs
>
> gesehen, die so verschwenderisch mit Resourcen umgehen, wie diese.

Dafür ist der Arduino auch nicht gedacht. Mir würde z.B. nicht in den 
Sinn kommen den Arduino in ner Industrieanlage einzusetzen wo ms schon 
über Erfolg oder Misserfolg entscheiden. Die Intention der MAcher war ja 
für Künstler und einfache DIY Projekte.

MfG EGS

[Fallobst (Gast)]

EGS schrieb:
> Jeder nach seiner Facon, ich steinige auch keinen weil er VW nicht mag
> oder Nissan liebt.
>
> Man muss halt schaun wie man mit zurecht kommt.

Das größte Manko ist, dass man nur schwer Projekte mit mehreren Dateien 
machen kann.

PS: In meinem aktuellen Projekt habe ich zurzeit über 30 
Source+Header-Dateien.

[EGS (Gast)]

Naja seis drum, man kann wenn man mag auch jeden anderen Compiler 
verwenden, wird ja von den Machern sogar erläutert wie, im Endeffekt 
sind es die Arduino Umgebung Software und die Hardware die man getrennt 
benutzen kann.

Aber wie gesagt lasst und dem TO helfen.

[F. F. (foldi)]

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.

[EGS (Gast)]

Also wie ich sehe sind da noch einige Farge offen was den Arduino 
angeht. Bitte schaut euch nur mal die FAQ unter:

http://arduino.cc/en/Main/FAQ

an...da werden einige sicherlich nen Aha-Effekt erleben ;)

Arduino kann ich mit Makerfile/AVR programmieren (dann z.B. ohne 
Bootlader) ich kann nen Arduino aber auch als ISP Benutzen um andere 
AVRs oder selbergebaute Arduino Boards zu flashen...

MfG EGS

[Michael (Gast)]

Danke für soviele Infos!
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???



volatile int state = LOW;


void setup()
{

  pinMode(13, OUTPUT);
  attachInterrupt(0, blink, RISING);

}

void loop()
{

  while(state == true){}
}



void blink()
{

  state = !state;
  tone(13, 5500, 5000);

  return;

}

[Fallobst (Gast)]

Michael schrieb:
> return;

OMG...........................
EGS hat es also geschafft. Das return braucht du hier NICHT!


Ansonsten ist dein Programm ein bisschen komisch. Die Variable state ist 
hier nutzlos - schau dir das nochmal an.

[Fabian O. (xfr)]

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 (Gast)]

Irgendwie bringt mich das hier gerade alles durcheinander! Soviele 
Beiträge!
Da ist es schwierig das gute herauszufiltern!

[EGS (Gast)]

Fallobst schrieb:
>> return;
>
>
>
> OMG...........................
>
> EGS hat es also geschafft. Das return braucht du hier NICHT!

Eigentlich nicht, der Interupt des Arduino macht das ja von selbst. Wenn 
man weiss was der Interupt macht seis gedankt :)

Aber zurück, ich hatte ihm da folgenden Code empfohlen:

EGS schrieb:
> volatile int state = LOW;
>
> void setup()
>
> {
>
>   pinMode(13, OUTPUT);
>
>   attachInterrupt(0, blink, Rising);
>
> }
>
> void loop() --> Dauerernde Abarbeitung
>
> {
>
> while(state == true) { //--> Wichtig hatte hier vorhin auch nur ein "="
>
> tone(13, 5500, 5000);
>
> }
>
> }
>
> void blink() -->Interuptroutine
>
> {
>
>   state = !state;
>
> }

Aber egal, wir wollen ja nicht abdriften. Hier würde wenn ein Interupt 
auftritt der Zustand von State negiert werden (aus true wird false und 
aus false wird true, je nach Zustand von "state). und im loop während 
"state" true ist der Ton erzeugt.

In seinem Programm läuft was ganz anderes:

er erzeugt in der Interuptroutine den Ton, und negiert den Zustand von 
State . Im loop macht er eigentlich nix sinnvolles, da er hier nur 
Währen state gleich true, nix tut.

[Markus M. (mark_m)]

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.

[Manuel X. (vophatec)]

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.

[Oliver (Gast)]

Karl Heinz Buchegger schrieb:
> Weils grade so schön passt
>
> http://c2.com/cgi/wiki?VoodooChickenCoding

Schöner link ;)

Wobei

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

es eigentlich noch besser trifft.

Oliver