delay() in Timer-Event ISR (Arduino)

[Roth (Gast)]

Guten Tag liebe Profis.

gleich werde ich wieder Schläge kriegen :D ...

Nachdem ich mich mit dem C bzw. C++ des Arduino nun etwas angefreundet 
habe, eine Frage zum Timer. Aus welchem Grund ist in ISR delay() 
gesperrt? Gibts dafür einen technischen Grund? Oder wurde das getan, um 
die Leute von "Dummheiten" abzuhalten? Also mit millis() und while() 
kann man 1 Sekunde Wartezeit z.B. ja auch realisieren, wenn man das 
will. Da millis() in der Warteloop auch weitergezählt wird, frage ich 
mich, wieso delay() den diesnst versagt. Ist ja nur eine Frage zur 
Theorie.

[MiMa (Gast)]

Wenn du nur einen Code hast, der stur Zeile für Zeile abgearbeitet wird, 
dann kann ich nichts gegen ein delay() einwenden.

Sobald du jedoch eine (mehrere) ISR hast wird es problematisch.

Der Sinn hinter der Verwendung von einer ISR ist, dass das Hauptprogramm 
seine Arbeit verrichten kann und nur kurz durch z.B. das Empfangen von 
neuen Daten, unterbrochen wird.
Verwendest du nun aber ein delay(1000) in deiner ISR, so wird das 
Hauptprogramm gestoppt und der uC macht 1s lang gar nichts. Wenn dich 
das nicht stört kannst du es schon machen (wenn auch nicht schön/gern 
gesehen)..

Schlimm wird es bei einer zweiten (niedriger oder gleich priorisierten) 
ISR. Bevor diese ausgeführt wird, muss zuerst die ISR1 abgearbeitet 
werden. Dadurch kann es zu sehr langen Verzögerungen führen.
Wenn ISR2 zeitlich kritisch ist..

[jois3 (Gast)]

Moin Roth,

> gleich werde ich wieder Schläge kriegen :D ...
Naja, immerhin weist Du es ja schon :-) Denn Dein Ansinnen ruft 
mindestens mildes Kopfschütteln aus.

Delay in einer ISR ist an sich schonmal seltsam. Kurz gesagt willst Du 
ISRs ausnahmslos (komplett ausnahmslos!) zeiteffizient abarbeiten. In 
einer Timer-ISR wird das ganze noch viel widersinniger. Wozu warten, 
wenn Du einfach aus der ISR raus und später wieder rein kannst?

Gruß, jois3

[Dr. Sommer (Gast)]

jois3 schrieb:
> Kurz gesagt willst Du
> ISRs ausnahmslos (komplett ausnahmslos!) zeiteffizient abarbeiten

Wenn man Controller mit verschachtelbaren Interrupts hat (Cortex-M z.B.) 
kann man unter bestimmten Umständen durchaus auch in ISRs längere Dinge 
tun. Ob das in Arduino so geht weiß ich aber nicht.

[Roth (Gast)]

jois3 schrieb:
> Moin Roth,
>
>> gleich werde ich wieder Schläge kriegen :D ...
> Naja, immerhin weist Du es ja schon :-) Denn Dein Ansinnen ruft
> mindestens mildes Kopfschütteln aus.

ja. Ich kenn euch doch :)

So ein paar Sonderfälle kamen mir schon vor die Finger. z.B. Taster 5Sek 
gedrückt => Reboot. Vor dem Reboot sollte eine LED 1 Sek. leuchten, als 
Taster-Feedback, also Rückmeldung für den User. Taster-Feedback muss 
zwar nicht sein, ist aber eine schöne Abrundung für eine Platine, die 
nur ein paar LEDs, aber kein Display hat.

Und wen juckt es schon, wenn vor einem Reboot der ISR nicht kann wie er 
will.

Ich habe mehrere Kanäle im ISR. Wenn ich einen blockiere (nur mal zum 
testen habe ich das probiert), habe ich festgestellt, dass die anderen 
noch weiter versorgt werden. Ohne sei() auszuführen () Hat mich zwar 
gewundert, ist aber so.

Ja, was soll ich sagen? Wer sich nicht mit Interrupts auskennt, sollte 
kein delay(1000) in Routinen verwenden, die 100x pro Sekunde aufgerufen 
werden. Wer es doch tut, und keine Regulatorik hat, der muss vor dem 
Lernen eben leiden. Ich wollte aber eigentlich , wieso delay() technisch 
deaktiviert ist. Das könnte meines Erachtens auch im ISR ohne weiteres 
funktionieren.

[Roth (Gast)]

"Ich wollte aber eigentlich wissen"  ... wollte ich eigentlich 
schreiben.

[Peter D. (peda)]

Roth schrieb:
> Aus welchem Grund ist in ISR delay()
> gesperrt?

Weil delay selber den Timerinterrupt benutzt, aber in einem 
Interrupthandler sind alle Interrupts gesperrt -> Deadlock.
Der AVR kennt keine Interruptlevel (bzw. nur einige neuere).
Man kann aber das Delay-Macro des GCC benutzen _delay_ms().

[Frank M. (ukw) (Moderator)]

Roth schrieb:
> Ich wollte aber eigentlich , wieso delay() technisch deaktiviert ist.

Vermutlich ist delay() unter Arduino über einen Timer-Interrupt 
realisiert. Da standardmäßig bei AVRs geschachtelte Interrupts nicht 
möglich sind (außer man trickst ziemlich herum), kommt der zu delay() 
gehörende Timer-Interrupt nicht zum Zuge. Daher wird delay() nicht mehr 
zurückkommen und Dein Programm hängt an dieser Stelle.

Beschreibe besser, was Du eigentlich machen möchtest. Meist kann man das 
vollkommen anders (und besser!) lösen.

[ÄXl (Gast)]

//C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\wiring.c
unsigned long micros() {
  unsigned long m;
  uint8_t oldSREG = SREG, t;
  
  cli();
  m = timer0_overflow_count;
#if defined(TCNT0)
  t = TCNT0;
#elif defined(TCNT0L)
  t = TCNT0L;
#else
  #error TIMER 0 not defined
#endif

#ifdef TIFR0
  if ((TIFR0 & _BV(TOV0)) && (t < 255))
    m++;
#else
  if ((TIFR & _BV(TOV0)) && (t < 255))
    m++;
#endif

  SREG = oldSREG;
  
  return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
}

void delay(unsigned long ms)
{
  uint32_t start = micros();

  while (ms > 0) {
    yield();
    while ( ms > 0 && (micros() - start) >= 1000) {
      ms--;
      start += 1000;
    }
  }
}

Weil delay() die Funktion micros() verwendet, diese wiederum dem Timer0.
Dessen Interrupt (wie alle anderen auch) ist aber gesperrt, wenn Du dich 
mit der Abarbeitung einer ISR beschäftigts. des I-Flag wird erst nach 
Rückkehr aus dieser durch die Hardware neu gesetzt.
--
Andererseit: ( ich bin da auch nicht soo der Experte... )

if ((TIFR0 & _BV(TOV0))

sollte doch, unabhängig vom globalen Freigabebit (I-Flag, TOIE0) 
trotzdem im TIFR0 das TOV0 Bit gesetzt werden wenn der Timer0 überläuft, 
oder?

[Einer K. (Gast)]

Roth schrieb:
> Ich habe mehrere Kanäle im ISR. Wenn ich einen blockiere (nur mal zum
> testen habe ich das probiert), habe ich festgestellt, dass die anderen
> noch weiter versorgt werden. Ohne sei() auszuführen () Hat mich zwar
> gewundert, ist aber so.

Unfug!

[Roth (Gast)]

Frank M. schrieb:
> Beschreibe besser, was Du eigentlich machen möchtest. Meist kann man das
> vollkommen anders (und besser!) lösen.

Habs ja schon umgesetzt. Wollte nur den Grund wissen, also reine 
Theorie.

Ich habe wie gesagt eine LED softwaremäßig an ein paar Taster gebunden. 
Feedbacks für Tastendruck, ergebnisabhängig, verschiedenes Blinken oder 
Leuchten. Alles timergesteuert. Das klappt zwar alles ohne Verzögerung, 
aber eine Blinksequenz sollte zu Ende laufen und nicht von einem anderen 
Event überschrieben werden, bevor z.B. die 1 Sekunde um ist.

Und dass der Timer gestoppt ist, wenn in einem ISR gewartet wird, konnte 
ich im Labor nicht feststellen. Bin in eine while(1){} Schleife 
gesprungen und -etwas verwundert- festgestellt, dass die LED 
(timergesteuert) immer noch blinkt.

Das hieße ja eigentlich, dass nur 1 Takt des Timers "hängt", und neue 
Takte noch ausgeführt werden. Code, der länger als 1 ISR-Takt dauert, 
ist natürlich mit static zu sperren , damit kein neuer Takt dem 
aktuellen in den Rücken fällt,.

[Roth (Gast)]

Arduino Fanboy D. schrieb:
> Unfug!

Und schon ist die Ruhe vorbei. Bitte gehe doch wieder weg und pöbel in 
anderen Themen. danke.

[Roth (Gast)]

ÄXl schrieb:
> Weil delay() die Funktion micros() verwendet, diese wiederum dem Timer0.

ÄXl ich habe Timer2 in Verwendung. Ich weiß nicht, wie die Timer 
priorisiert sind. Les mich da mal demnächst besser ein. Im Moment bin 
ich noch am tüfteln + probieren, reine Spielwiese

[Georg M. (g_m)]

Roth schrieb:
> , wieso delay() technisch deaktiviert ist.

Since delay() requires interrupts to work, it will not work if called 
inside an ISR.

delayMicroseconds() does not use any counter, so it will work as normal.

Generally, an ISR should be as short and fast as possible.

https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/

[MiMa (Gast)]

> Roth schrieb:
>> Ich habe mehrere Kanäle im ISR. Wenn ich einen blockiere (nur mal zum
>> testen habe ich das probiert), habe ich festgestellt, dass die anderen
>> noch weiter versorgt werden. Ohne sei() auszuführen () Hat mich zwar
>> gewundert, ist aber so.

Eine ISR mit while(1); blockiert?
Wenn eine andere ISR dann noch aufgerufen wird, dann muss diese höher 
priorisiert sein.

[Einer K. (Gast)]

Roth schrieb:
> Arduino Fanboy D. schrieb:
>> Unfug!
>
> Und schon ist die Ruhe vorbei. Bitte gehe doch wieder weg und pöbel in
> anderen Themen. danke.

Meister!
Schaue in die Doku deines AVR und deiner Lieblingssprache.

Und du wirst erfahren, das beim/vorm Eintritt in die ISR Interrupts 
gesperrt werden. Diese Sperre wird per Default erst beim Austritt wieder 
aufgehoben.

Somit ist deine Geschichte ein Märchen.

Was du da in der Realität veranstaltet hast, ist geheim.
Zumindest sehe ich es nicht.

Zeige ein einfaches Beispiel, von dem, was du da tust.
Und ich sage dir dann, ob und wenn, dann warum, da weiter ISRs 
aufgerufen werden, obwohl angeblich Interrupts abgeschaltet sind.

Du hast da ganz offensichtlich irgendein Verhalten deines µC 
fehlinterpretiert.
Das ist ok, passiert jedem mal.

Aber an dieser Stelle ist das nachprüfbar zu widerlegen.
Du erzählst Märchen.
Unwahrheiten.
Und ab jetzt, bei Wiederholungen, nach dem ich dir gesagt habe, dass das 
Unsinn ist, wird aus dem Märchen eine Lügengeschichte.

Märchen enthalten wenigstens einen Kern Wahrheit, oder eine Empfehlung.
Deine Geschichte nicht.

OK, du magst es so wahrgenommen haben.
Aber mit der Realität, was wirklich passiert ist, hat das wenig/nichts 
zu tun.

Roth schrieb:
> Und dass der Timer gestoppt ist, wenn in einem ISR gewartet wird, konnte
> ich im Labor nicht feststellen. Bin in eine while(1){} Schleife
> gesprungen und -etwas verwundert- festgestellt, dass die LED
> (timergesteuert) immer noch blinkt.
Der Timer wird nicht gestoppt!
Der läuft unbeirrt weiter.

Roth schrieb:
> Das hieße ja eigentlich, dass nur 1 Takt des Timers "hängt", und neue
> Takte noch ausgeführt werden. Code, der länger als 1 ISR-Takt dauert,
> ist natürlich mit static zu sperren , damit kein neuer Takt dem
> aktuellen in den Rücken fällt
Auch eine lustige Geschichte!
Dieses mal sogar mit der Empfehlung, mit static zu sperren.

Würdest du bitte den Absatz nochmal überdenken...

[ÄXl (Gast)]

sei() wird ja auch schon vom Framework aufgerufen. Damit hast Du ja nix 
zu tun. (main.cpp ruft init auf, darin: sei()) gleich über der og. 
delay() Routine inder wiring.cpp zu finden.
danach erst kommt "setup", dann das "loop".

"C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\main.cpp"

Du hattest doch den Quelltext nun schon offen. Sieh doch einfach nach, 
was passiert!
Stell' mal deinem while(1) ein cli() voran. weshalb sollte eine While(1) 
deine Ints sperren?

[Roth (Gast)]

Arduino Fanboy D. schrieb:
> Meister!
ja, danke :)

> Schaue in die Doku deines AVR und deiner Lieblingssprache.
Piano. Ich habe nach deiner Anregung 100 Bücher gekauft, aber erst 58 
gelesen. Bitte vergib mir, o Herr

MiMa schrieb:
> Eine ISR mit while(1); blockiert?
> Wenn eine andere ISR dann noch aufgerufen wird, dann muss diese höher
> priorisiert sein.

Ja. Ich habe das aber selbst nie richtig glauben können, und noch mal 
alles durchforstet. Bisher ging ich davon aus, dass cli()...sei() 
zwingend symetrisch organisiert sind (wie z.B. push und pop in Asm). 
Wenn ISR gesperrt ist (also sozusagen "Status cli()" vorliegt), und im 
weiteren Code die Folge {cli(); blablabla; sei()} vorkommt, ging ich 
davon aus, dass nach dem sei() "Status cli()" immer noch vorliegt ( 
2xcli() und nur 1x sei() ). Es ist aber wohl so, dass die letzte Order 
gewinnt. Da ich bei atomaren Operationen cli() und sei() verwende (zwar 
nicht im ISR aber in Serviceroutinen, die vom ISR gelegentlich verwendet 
werden), war es also im Endeffekt so, dass ISR durch das abschließende 
sei() einer Serviceroutine freigeschaltet war, obwohl dort noch Code 
ausgeführt worden ist. Habe ich gar nicht gemerkt :) Und daher ging auch 
while(1); problemlos. Es war ja nur der eine Kanal blockiert, die 
anderen wurden noch vom Taktgeber versorgt.

Weil ich es aus Assembler gewohnt bin, im Timerinterrupt "ohne Netz" zu 
arbeiten (also Taktgeber rattert weiter, auch wenn gerade ein Event 
bearbeitet wird), ist mir das nicht aufgefallen, dass ISRs beim Arduino 
standardmäßig gesperrt sind, wenn "drinnen" gerade was ausgeführt wird. 
Wie oben geschrieben, war ich zwar verwundert, dass sich while(1); nicht 
aufhängt, fand das aber eher positiv. Wenn der Kanal nicht gesperrt 
gewesen wäre, hätte es vermutlich im nullkommanix eine Stack Overflow 
gegeben ;)

[Wolfgang (Gast)]

Roth schrieb:
> Aus welchem Grund ist in ISR delay()
> gesperrt? Gibts dafür einen technischen Grund?

Nichtmal millis() wird dann weiter laufen, d.h. Zeitsteuerungen 
funktionieren nicht mehr.

[Roth (Gast)]

Bin mal so frei, meine Spielwiese offen zu stellen. Die ISR ohne das (im 
PDF rot markierte) Testzeugs läuft einwandfrei. Vielleicht nützt es dem 
einen oder anderen ja mal.


> Was du da in der Realität veranstaltet hast, ist geheim.
> Zumindest sehe ich es nicht.
So so. Du siehst es also nicht.

Und jetzt, kannst du es sehen?

// Ein kleines ISR Programm, um LEDs mit konfigurierbarer Sequenz blinken zu lassen.
// Das rote (nur im PDF ist es rot) ist zum testen eingefügt, um zu sehen, wie der 
// Timer Interrupt sich verhält, wenn ein LED-Kanal behindert wird.

/*************************** D E F I N E S ***************************************************/

// besser lesbar
#define byte          uint8_t
#define word         uint16_t
#define dword        uint32_t

// Allgemein
#define NC                255  // Default für "unbenutzt" (z.B. Pin)

// Timer 2 Interrupt: Haupttakt konfigurieren
#define MAIN_CLK          160  // Interrupts pro Sekunde (Timer-Takt)
#define OCR2A_KOR           2  // Manueller OCR2A Korrekturfaktor

/**********************/
/* LM: LED-Management */
/**********************/

// LM: Allgemeine Einstellungen
#define LM_COUNT            4  // Anzahl Kanäle
#define LM_CLOCK           20  // Timer-Prescaler Default

// LM_01: Kanal 1 konfigurieren (LED rot)
#define LM_01_IDX           0  // Index im Arbeitsbereich
#define LM_01_PIN          37  // Pin-Nr.

// LM_02: Kanal 2 konfigurieren (LED gelb)
#define LM_02_IDX           1  // Index im Arbeitsbereich
#define LM_02_PIN          39  // Pin-Nr.

// LM_03: Kanal 3 konfigurieren (LED grün)
#define LM_03_IDX           2  // Index im Arbeitsbereich
#define LM_03_PIN          41  // Pin-Nr.

// LM_04: Kanal 4 konfigurieren
#define LM_04_IDX           3  // Index im Arbeitsbereich
#define LM_04_PIN          NC  // Pin-Nr.

// LM: Verwendete Kanäle (Sprechender Tabellenindex)
#define LED_ROT     LM_01_IDX  // LED rot
#define LED_GELB    LM_02_IDX  // LED gelb
#define LED_GRUEN   LM_03_IDX  // LED grün

/*************************** T Y P E S *******************************************************/

// LM: Struktur des Arbeitsbereichs
struct tLM {
       byte Pin;               // Pin-Nr. (NC=ungenutzt)
       word TPrescaler;        // Timer-Prescaler (0=Kanal deaktiviert)
       word TCounter;          // Prescaler-Counter
       byte InUse;             // ISR-Sperrflag (1=Kanal wird gerade verwendet)
       byte Pattern;           // LED-Blinkmuster
       byte BitPointer;        // Bit-Zeiger
};

/*************************** G L O B A L E  V A R I A B L E N ********************************/

// LM: LED-Arbeitsbereich anlegen
volatile tLM LM[LM_COUNT];

/*************************** F O R W A R D S  ************************************************/

void mySetup();

/*************************** A D M I N I S T R A T I O N S T O O L S *************************/

/***************************************************************************/
/* Zeigt die Millisekunden mit Nachkommastellen seit dem letzten Aufruf an */
/*                                                                         */
/* fNoPrint : 1=initialisiert nur den Zeitstempel (kein Ausgabe)           */
/***************************************************************************/
void PrintMillisDelta(byte iKanal=0, byte fNoPrint=0) {
  static dword Timestamp[10];
  if (!fNoPrint)
     {Serial.println( (micros() - Timestamp[iKanal]) / 1000.0);}
  Timestamp[iKanal] = micros();
}

/***************************************/
/* Byte als Binärzahl seriell ausgeben */
/***************************************/
void PrintBinaer(byte i, byte fMitBitNr=0, byte fNoLN=0) {
  if (fMitBitNr)
     {Serial.println("76543210");}
  for (byte n=0; n<8; n++)
    {Serial.print(i & (128 >> n) ? 1 : 0);}
  if (!fNoLN)
     {Serial.println("");}
}

/*************************** I N I T I A L I S I E R U N G ***********************************/

void setup() {

  /****************************************/
  /* Serielle Schnittstelle und Admintool */
  /****************************************/
  PrintMillisDelta(0, 1);                           // Zeitmesser 0 initialisieren
  Serial.begin(9600);                               // Geschwindigkeit der Schnittstelle zum PC
  delay(250);                                       // kurz warten
  Serial.println("(0) Hallo Meister");

  /*************************************/
  /* LM: LED-Management initialisieren */
  /*************************************/
  for (byte ix=0; ix<LM_COUNT; ix++) {
    tLM *p;                                         // Hilfspointer
    p = &LM[ix];                                    // Zeiger auf Arbeitsbereich

    // LM: Allgemeine Einstellungen
    p->TPrescaler = 0;                              // Timer-Prescaler
    p->InUse      = 0;                              // ISR-Sperrflag

    // LM: Spezifische Einstellungen
    switch (ix) {
      case LM_01_IDX:                               // Kanal 1
           p->Pin        = LM_01_PIN;               // Pin-Nr.
           break;
      case LM_02_IDX:                               // Kanal 2
           p->Pin        = LM_02_PIN;               // Pin-Nr.
           break;
      case LM_03_IDX:                               // Kanal 3
           p->Pin        = LM_03_PIN;               // Pin-Nr.
           break;
      case LM_04_IDX:                               // Kanal 4
           p->Pin        = LM_04_PIN;               // Pin-Nr.
           break;
      default:
           p->Pin        = NC;                      // Ungültiger Index, keine Pin-Nr.
    } // Ende Spezifische Einstellungen

    // LM: Pin als Ausgang definieren
    if (p->Pin != NC) {                             // Nur wenn eine Pin definiert ist
       pinMode(p->Pin, OUTPUT);                     // Pin auf OUTPUT schalten
       digitalWrite(p->Pin, LOW);                   // LED ausschalten
    } // Ende Pin als Ausgang definieren

  } // Ende LED-Management initialisieren

  /**************************************************/
  /* SM: Interrrupt konfigurieren und Timer starten */
  /**************************************************/
  cli();                                            // Interrupts sperren
  TCNT2 = 0;                                        // Timer Counter 2
  TCCR2A = 0;                                       // Timer Counter Controll Register A löschen
  TCCR2B = 0;                                       // Timer Counter Controll Register B löschen
  OCR2A = (16000000.0/(1024.0*MAIN_CLK))+OCR2A_KOR; // Vergleichswert in Output Compare Reg. A
  TCCR2B |= (1<<CS22) | (1<<CS21) | (1<<CS20);      // Prescaler 1024
  TCCR2A |= (1<<WGM21);                             // CTC-Mode ein
  TIMSK2 |= (1<<OCIE2A);                            // Output Compare A Match Interrupt Enable
  sei();                                            // Interrupts erlauben

  /**************************************/
  /* Vordergrundprogramm initialisieren */
  /**************************************/
  Serial.print("(0) HG-Setup beendet. Dauer: ");
  PrintMillisDelta(0);
  mySetup();                                        // VG-Setup
  Serial.print("(0) VG-Setup beendet. Dauer: ");
  PrintMillisDelta(0);

} // Ende setup()

/*************************** T I M E R  E V E N T ********************************************/

/***************************************/
/* Timer 2 Interrrupt 160x pro Sekunde */
/***************************************/
ISR(TIMER2_COMPA_vect) {

  /****************/
  /* Nur zum Test */
  /****************/
  sei();  // Das ist eine Männer-ISR!

  /**********************/
  /* LM: LEDs versorgen */
  /**********************/
  for (byte ix=0; ix<LM_COUNT; ix++) {
    tLM *p;                                         // Hilfspointer
    p = &LM[ix];                                    // Zeiger auf Arbeitsbereich

    // LM: Kanal aktiviert?
    if (p->TPrescaler == 0) {/*schon fertig*/}      // Prescaler=0 sperrt die Ausführung

    // LM: Kanal gesperrt?
    else if (p->InUse) {/*besetzt*/}                // ISR-Sperrflag: Kanal ist in Bearbeitung

    // LM: Prescaler abgelaufen?
    else if (++p->TCounter >= p->TPrescaler) {      // Der Timerevent verwendet einen Prescaler
       p->TCounter = 0;                             // Auslösewert erreicht: Counter löschen

       // LM: Kanal sperren
       p->InUse = 1;                                // Nicht stören

// XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
       // Eingefügt zum Testen des Timers
       if (ix == LED_GELB) {                                  // Kanal der gelben LED
          PrintMillisDelta(2, 1);                             // blockieren, um zu sehen,
          Serial.println("(2) Gelbe LED 5 Sek blockiert");    // ob die anderen LEDs noch
          word iTS = millis() + 5000;                         // blinken. Sie blinken nur
          while(iTS > millis());                              // dann, wenn zu ISR-Begin
          Serial.print("(2) Gelbe LED wieder frei. Dauer: "); // ein sei() eingefügt wurde.
          PrintMillisDelta(2);
       }
// XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

       // LM: 8 Bits ausgegeben?
       if (++p->BitPointer > 8)                     // Wenn 8 Bits ausgegeben sind
         {p->BitPointer = 0;}                       // Bitzeiger wieder auf 0

       // LM: LED ansteuern
       byte f = p->Pattern & (1 << p->BitPointer);  // Bit auslesen
       digitalWrite(p->Pin, f);                     // LED umschalten

       // LM: Kanalsperre aufheben
       p->InUse = 0;                                // Kanal wieder freigeben

    } // Ende Prescaler abgelaufen?
  } // Ende LEDs versorgen
} // Ende ISR

/*************************** B A S I S F U N K T I O N E N ***********************************/

/******************************************************************/
/* LM: Konfiguriert einen LED-Kanal                               */
/*                                                                */
/* iKanal     : Nummer der LED (Tabellenindex, beginnend ab 0)    */
/* iPattern   : Bitmuster                                         */
/* iPrescaler : Blinkgeschwindigkeit Standard: 8 Bit pro Sekunde) */
/******************************************************************/
void LM_SetLED(byte iKanal,
               byte iPattern,
               word iPrescaler = LM_CLOCK) {

  tLM *p;                                // Hilfspointer
  p = &LM[iKanal];                       // Zeiger auf Arbeitsbereich

  // LM: Kanal konfigurieren
  cli();                                 // Interrupts verbieten
  p->Pattern    = iPattern;              // LED-Bitmuster
  p->BitPointer = 0;                     // Bit-Zeiger auf 0
  p->TCounter   = 0;                     // Prescaler-Counter löschen
  p->TPrescaler = iPrescaler;            // Prescaler übergeben
  sei();                                 // Interrupts erlauben
}

/*************************** V O R D E R G R U N D R O G R A M M *****************************/

void mySetup() {
  LM_SetLED(LED_ROT,   0b11110000);
  LM_SetLED(LED_GELB,  0b11001100);
  LM_SetLED(LED_GRUEN, 0b10101010);

  Serial.println("(1) Start delay(1000)");
  PrintMillisDelta(1, 1);
  delay(1000);
  Serial.print("(1) Ende delay(1000). Dauer: ");
  PrintMillisDelta(1);

  LM_SetLED(LED_GRUEN, 0b00001111);
}

void loop() {
}

[Roth (Gast)]

4 LEDs anschließen und die Portnummern in DEFINES eintragen. Dann 
einfach laufen lassen und auch den Monitor beobachten.

[Roth (Gast)]

Arduino Fanboy D. schrieb:
> Roth schrieb:
>> Das hieße ja eigentlich, dass nur 1 Takt des Timers "hängt", und neue
>> Takte noch ausgeführt werden. Code, der länger als 1 ISR-Takt dauert,
>> ist natürlich mit static zu sperren , damit kein neuer Takt dem
>> aktuellen in den Rücken fällt
> Auch eine lustige Geschichte!
> Dieses mal sogar mit der Empfehlung, mit static zu sperren.
>
> Würdest du bitte den Absatz nochmal überdenken...

Der Arduino Fanboy, wenn er nicht so frech wäre, würde vielleicht sogar 
positiv glänzen in der Welt. Aber so freut sich nur der Gilb.

Immerhin hat der Fanboy ja rausgefunden, dass es ohne sei() nicht geht. 
Und das habe ich in der Tat übersehen bzw. die cli()...sei() Systematik 
als verschachtelbares Konstrukt eingeschätzt - was es aber nicht ist-.

[Einer K. (Gast)]

Roth schrieb:
> Immerhin hat der Fanboy ja rausgefunden, dass es ohne sei() nicht geht.

Das brauche ich nicht herauszufinden!
Sowas weiß ich!

Denn meine Kompetenz in Sachen AVR beruht auf Wissen und Erfahrung.

Deine Kompetenz liegt offensichtlich eher im Verbohrt sein und in einer 
lebhaften Einbildungskraft, gepaart mit einer beachtenswerten 
Überheblichkeit und Arroganz.

Roth schrieb:
> Der Arduino Fanboy, wenn er nicht so frech wäre,

Erinnere dich an unsere ersten Begegnungen....
Wie du mich da herabgewürdigt hast, nur weil du zu 
blöd/borniert/beschränkt warst meine Antworten zu kapieren?

Ich bin ein Spiegel!
Du hast Verachtung gesät, und du wirst Verachtung ernten.

Roth schrieb:
> Und schon ist die Ruhe vorbei. Bitte gehe doch wieder weg und pöbel in
> anderen Themen. danke.
Ist das freundlich?
Nee, oder?

Wie kannst du dich dann wundern, darüber mokieren, dass ich dir einen 
Tick härter komme, als ich es bei anderen tue?

[c-hater (Gast)]

Roth schrieb:

> Weil ich es aus Assembler gewohnt bin, im Timerinterrupt "ohne Netz" zu
> arbeiten (also Taktgeber rattert weiter, auch wenn gerade ein Event
> bearbeitet wird), ist mir das nicht aufgefallen, dass ISRs beim Arduino
> standardmäßig gesperrt sind, wenn "drinnen" gerade was ausgeführt wird.

1)
Auch, wenn man in Asm programmiert, sind beim AVR8 in einer ISR 
natürlich standardmäßig die Interrupts gesperrt, denn das ist eine 
Eigenschaft der Maschine und nicht der Sprache. Dementsprechend kann man 
auch in allen Sprachen das Verhalten ändern, indem man irgendwo in der 
ISR SREG_I setzt, sei es durch eine sei-Instruktion oder auch durch 
irgendein anderes Konstrukt. Dann kann nachfolgender Code der ISR durch 
einen Interrupt unterbrochen werden. Das Problem dabei ist nur: es kann 
auch der eigene sein, was entweder einen Mechanismus erfordert, genau 
nur diesen zu sperren oder ein genau durchdachtes (und korrekt 
umgesetztes) Timing aller ISRs des Systems. Ansonsten droht 
Stackunterlauf.

2)
Ob die Timer laufen oder nicht, hat mit Interrupts überhaupt nix zu 
schaffen. Die laufen, wenn einmal gestartet, immer lustig weiter, ganz 
egal, ob die Interrupts gesperrt sind oder nicht. Auch wieder: 
Eigenschaft der Maschine, nicht der Sprache. Interrupts braucht man nur, 
um auf Timerereignisse mit eigenem Code reagieren zu können. Für die 
reine Ausgabe über die OC-Anschlüsse braucht man sie nicht, da ist die 
MCU überhaupt nicht involviert. Das hast du offensichtlich niemals 
kapiert.

[Roth (Gast)]

Arduino Fanboy D. schrieb:
> Ich bin ein Spiegel!

ja genau.

https://newstopaktuell.files.wordpress.com/2014/02/fluoride-und-so-lc3bcgt-der-spiegel.jpg

[Max M. (max_m250)]

Delays sind in Arduino innerhalb von ISRs gesperrt? Oh je noch ein Grund 
das nicht zu benutzen. Ja ja man darf einem Interrupt nicht unnötig 
verzögern, bla bla, weiß wirklich jeder. Mir fallen trzd auf Anhieb eine 
handvoll Fälle ein, wo ein Delay von wenigen µs im Interrupt sinnvoll u 
okay ist. Was bringt eine Entwicklungsumgebung die mir Sachen verbietet 
nur weil einige damit nicht umgehen können?!

[Uff Passe (Gast)]

Max M. schrieb:
> Was bringt eine Entwicklungsumgebung die mir Sachen verbietet
> nur weil einige damit nicht umgehen können?!

Arduino ist keine Entwicklungsumgebung sondern eine Krücke
für sonst nicht Gehfähige.

[Ich (Gast)]

Max M. schrieb:
> Delays sind in Arduino innerhalb von ISRs gesperrt? Oh je noch ein
> Grund das nicht zu benutzen. Ja ja man darf einem Interrupt nicht
> unnötig verzögern, bla bla, weiß wirklich jeder. Mir fallen trzd auf
> Anhieb eine handvoll Fälle ein, wo ein Delay von wenigen µs im Interrupt
> sinnvoll u okay ist. Was bringt eine Entwicklungsumgebung die mir Sachen
> verbietet nur weil einige damit nicht umgehen können?!

Viel verstehst du auch nicht....
Und wenn, dann auch gerne das falsche.

[Michael U. (amiga)]

Hallo,

Max M. schrieb:
> Mir fallen trzd auf Anhieb eine
> handvoll Fälle ein, wo ein Delay von wenigen µs im Interrupt sinnvoll u
> okay ist.

dann mach es doch einfach. µs wird nicht per Timer realisiert, geht also 
auch in einer ISR in der ArduinoIDE.
Du kannst auch gern  __asm__("nop\n\t"); benutzen, niemand hindert Dich 
daran

Gruß aus Berlin
Michael

[Sven K. (quotschmacher)]

Passduuff schrieb im Beitrag #5628192:
> Diese langweilige Laberei von "Krücke" ist selbst eine Krücke.
> Und zwar eione für nicht GehWILLIGE

bezieht sich wohl eher auf die ide denn auf die hardware. lässt sich 
aber aus dem kontext erschliessen...

[M. K. (sylaina)]

Max M. schrieb:
> Mir fallen trzd auf Anhieb eine
> handvoll Fälle ein, wo ein Delay von wenigen µs im Interrupt sinnvoll u
> okay ist.

Mir nicht. Wer im Interrupt Zeit hat zu warten, für den ist der 
Interrupt wahrscheinlich nicht die richtige Lösung sondern bestenfalls 
ein Notbehelf.

Uff Passe schrieb:
> Arduino ist keine Entwicklungsumgebung sondern eine Krücke
> für sonst nicht Gehfähige.

Der Erfolg des Arduino zeigt wohl offensichtlich, dass es sehr viele, 
nach deine Definition, nicht Gehfähige gibt ;)

Ich hab mich auch nicht wirklich mit der Arduino IDE anfreunden können, 
finde aber das Konzept einfach großartig und gelungen. Als Krücke würde 
ich Arduino nicht bezeichnen.

[Veit D. (devil-elec)]

Ich frage mich nachdem das Programm gesehen habe wofür man zum LED 
blinken überhaupt zusätzliche Timer Interrupts benötigt. Das kann man 
alles mit millis und Merkern erschlagen.

[M. K. (sylaina)]

Veit D. schrieb:
> Ich frage mich nachdem das Programm gesehen habe wofür man zum LED
> blinken überhaupt zusätzliche Timer Interrupts benötigt. Das kann man
> alles mit millis und Merkern erschlagen.

Vielleicht weil man beginnt sich mit Interrupts zu beschäftigen. So hab 
ich auch den Einstieg in Interrupts gemacht bei mir: Die LED nicht mehr 
via delay blinken lassen sondern via ISR ;)

[Veit D. (devil-elec)]

Ich hoffe nur zum lernen, nicht das es Gewohnheit wird für jeden Mist 
einen Interrupt zu verwenden.

[M. K. (sylaina)]

Veit D. schrieb:
> Ich hoffe nur zum lernen, nicht das es Gewohnheit wird für jeden Mist
> einen Interrupt zu verwenden.

Naja, muss ja nicht unbedingt schlecht sein. Ich hab fast nur noch 
Interrupt gesteuerte Programmabläufe.

[Hannes J. (hannes_j)]

Passduuff schrieb im Beitrag #5628192:
> Uff Passe schrieb:
>> Arduino ist keine Entwicklungsumgebung sondern eine Krücke
>> für sonst nicht Gehfähige.
>
> Sagt wer?
> Arduino ist eine großartige Einstiegshilfe für Menschen, die keinen
> Lötkolben haben oder keine Lust oder keinen Sinn darin sehen, sich erst
> ein Board zu bauen, bevor sie ein paar Zeilen Programmcode laufen lassen
> können. Diese langweilige Laberei von "Krücke" ist selbst eine Krücke.
> Und zwar eione für nicht GehWILLIGE

Dafür gibt es Evaluation-Boards. Arduino ist eher für Leute die von µCs 
nicht die geringste Ahnung haben und einfach irgendwie irgendwas zum 
laufen kriegen wollen, ohne so richtig zu verstehen was da eigentlich 
los ist. Wer zu Arduino greift weil er einfach nicht löten will hat 
definitiv iwas falsch verstanden.

[Hannes J. (hannes_j)]

Michael U. schrieb:
> Hallo,
>
> Max M. schrieb:
>> Mir fallen trzd auf Anhieb eine
>> handvoll Fälle ein, wo ein Delay von wenigen µs im Interrupt sinnvoll u
>> okay ist.
>
> dann mach es doch einfach. µs wird nicht per Timer realisiert, geht also
> auch in einer ISR in der ArduinoIDE.
> Du kannst auch gern  __asm__("nop\n\t"); benutzen, niemand hindert Dich
> daran
>
> Gruß aus Berlin
> Michael

Also soll ich in meinem mit 20 MHz getakteten Atmega 40x die Anweisung 
_NOP(); schreiben anstatt _delay_us(2);?

Na glückwunsch, da hat aber jmd. Ahnung wie man sich unübersichtliche 
Quelltexte bastelt..

[Hannes J. (hannes_j)]

M. K. schrieb:
> Max M. schrieb:
>> Mir fallen trzd auf Anhieb eine
>> handvoll Fälle ein, wo ein Delay von wenigen µs im Interrupt sinnvoll u
>> okay ist.
>
> Mir nicht. Wer im Interrupt Zeit hat zu warten, für den ist der
> Interrupt wahrscheinlich nicht die richtige Lösung sondern bestenfalls
> ein Notbehelf.

Mir schon.

[M. K. (sylaina)]

Hannes J. schrieb:
> M. K. schrieb:
>> Max M. schrieb:
>>> Mir fallen trzd auf Anhieb eine
>>> handvoll Fälle ein, wo ein Delay von wenigen µs im Interrupt sinnvoll u
>>> okay ist.
>>
>> Mir nicht. Wer im Interrupt Zeit hat zu warten, für den ist der
>> Interrupt wahrscheinlich nicht die richtige Lösung sondern bestenfalls
>> ein Notbehelf.
>
> Mir schon.

Damit wollte ich lediglich ausdrücken: Wer im Interrupt mit delay_us 
oder delay_ms warten will, für den gibt es höchstwahrscheinlich eine 
bessere Lösung als in der ISR zu warten.
Natürlich kann ich mir auch vorstellen mithilfe von delay in einer ISR 
zu warten, aber idR ist das eine denkbar schlechte Lösung.

[c-hater (Gast)]

M. K. schrieb:

> Damit wollte ich lediglich ausdrücken: Wer im Interrupt mit delay_us
> oder delay_ms warten will, für den gibt es höchstwahrscheinlich eine
> bessere Lösung als in der ISR zu warten.

Oft ist das so, wahrscheinlich sogar meistens, aber nicht immer.

> Natürlich kann ich mir auch vorstellen mithilfe von delay in einer ISR
> zu warten, aber idR ist das eine denkbar schlechte Lösung.

Manchmal ist es sogar die einzig mögliche, um ein bestimmtes Ziel zu 
erreichen. Nehmen wir z.B. mal an, du wolltest auf einem AVR8 (ohne 
dedizierte USB-Hardware) einen USB-Host umsetzen, es soll aber in 
gewissem Maße möglich bleiben, konkurrierende Interrupts zu betreiben. 
Oder, Variante praktisch der gleichen Aufgabe: Ausgabe an einen 
VGA-Monitor, ebenfalls mit der Möglichkeit, konkurrierende Interrupts zu 
betreiben. In beiden Fällen führen die Anforderungen des zu erzeugenden 
Signals fast zwingend dazu, dass du in der ISR warten musst. OK, ist 
dann kein dummes Delay, sondern ein komplizierteres Konstrukt mit dem 
Ziel, die variable Latenz der Konkurrenz aufzuessen, wenn diese sie 
gerade nicht benötigt hat, aber es ist und bleibt Warten in der ISR 
durch Verbrennung von Rechenzeit.

Ja, man könnte in beiden Fällen sicherlich mit geeigneter Hardware 
(insbesondere USART im SPI-Mode) dasselbe Ergebnis auch ohne dieses 
Warten erzielen, dabei entstehen aber zwei Probleme: 1) nicht jeder AVR8 
verfügt überhaupt über derartige Hardware und 2) schränkt das 
typischerweise die Auswahl der Pins ganz erheblich ein.

[Dieter F. (Gast)]

Hannes J. schrieb:
> Dafür gibt es Evaluation-Boards. Arduino ist eher für Leute die von µCs
> nicht die geringste Ahnung haben und einfach irgendwie irgendwas zum
> laufen kriegen wollen, ohne so richtig zu verstehen was da eigentlich
> los ist.

Das sehe ich anders.

Ich nutze "Arduino" auf 2erlei Arten:

1. Die Hardware, prima Steckbrett-geeignet (Nano, Micro)

2. Die Entwicklungsumgebung mit div. Librarys, mit welcher neue Sensoren 
etc.
   sich schnell einbinden und testen lassen

Für Q&D - und durchaus auch für ernstere Anwendungen ohne zeitkritische 
Teile reicht es aus meiner Sicht vollauf aus. Es zwingt mich niemand, 
millis() etc. zu nutzen. Wenn ich die volle Kontrolle über Interrupts, 
Timer etc. haben will nutze ich Variante 1 bzw. andere, auch 
steckbrettfähige (für die Entwicklung), MC's.

Um irgendeinen Sensor etc. auf die Schnelle auszuprobieren (auch auf dem 
Steckbrett) nutze ich oft die Entwicklungsumgebung / Librarys. Warum 
auch nicht - geht schnell und man kann das Verhalten recht gut 
einschätzen.

Zeitkritische Anwendungen entwickle ich in C (im Atmel Studio - ich 
weiß, ist verpönt bei manchen) ggf. mit Inline-Assembler. Reinen 
Assembler habe ich sei Jahren nicht mehr genutzt (@ C-Hater - ich bin 
auch kein professioneller MC-Entwickler).

Wenn ich es brauche skaliere ich halt die Hardware/den MC hoch - es ist 
nur für mich (keine Serienfertigung) - und der Weg ist das Ziel :-)

Ein wenig Ahnung habe ich schon - daher distanziere ich mich von Hannes 
Aussage.

[Einer K. (Gast)]

Hannes J. schrieb:
> Also soll ich in meinem mit 20 MHz getakteten Atmega 40x die Anweisung
> _NOP(); schreiben anstatt _delay_us(2);?

Wer sagt das?
Das kannst du tun!
Aber von "sollen" war keine Rede.

Auf Arduino steht die AVR C-Lib vollumfänglich zur Verfügung.
Die gleichen delay Funktionen, wie im Atmel Studio.

Zusätzlich noch die Arduino eigenen Delay Funktionen. Und diese, nur 
diese, benötigen selber Timer Interrupts. Darum funktionieren sie nicht 
in ISR.
Das ist logisch nachvollziehbar.
Das ist zwangsläufig so.
Das ist dokumentiert.

Max M. schrieb:
> Was bringt eine Entwicklungsumgebung die mir Sachen verbietet
> nur weil einige damit nicht umgehen können?!
Das ist Unsinn!
Da ist nichts verboten.


--

Es gibt allerdings noch einen Grund, warum man kein Arduino delay() in 
ISR nutzen sollte, selbst wenn man die Interrupts händisch aktiviert.
delay() ruft intern yield() auf. Auch bei AVRs. Einfach um eine 
Möglichkeit zu haben, die in delay() zu verplempernde Zeit noch anders 
nutzen zu können.
Hat man zufällig ein Multitasking System unter den Fingern (ja, manche 
Arduino Dinger haben das, sind so) stehen die Chancen sehr gut, dass man 
dabei auf die Fresse fällt.
Mit Karracho.

[Roth (Gast)]

Veit D. schrieb:
> Ich hoffe nur zum lernen, nicht das es Gewohnheit wird für jeden Mist
> einen Interrupt zu verwenden.

Veit D. schrieb:
> Ich frage mich nachdem das Programm gesehen habe wofür man zum LED
> blinken überhaupt zusätzliche Timer Interrupts benötigt. Das kann man
> alles mit millis und Merkern erschlagen.

Kannst du den Code "mit millis und Merkern" bitte mal veröffentlichen? 
Das sind ja bestimmt nur ein paar Zeilen. Danke.

[Roth (Gast)]

Hannes J. schrieb:
> Passduuff schrieb im Beitrag #5628192:
>> Uff Passe schrieb:
>>> Arduino ist keine Entwicklungsumgebung sondern eine Krücke
>>> für sonst nicht Gehfähige.
>>
>> Sagt wer?
>> Arduino ist eine großartige Einstiegshilfe für Menschen, die keinen
>> Lötkolben haben oder keine Lust oder keinen Sinn darin sehen, sich erst
>> ein Board zu bauen, bevor sie ein paar Zeilen Programmcode laufen lassen
>> können. Diese langweilige Laberei von "Krücke" ist selbst eine Krücke.
>> Und zwar eione für nicht GehWILLIGE
>
> Dafür gibt es Evaluation-Boards. Arduino ist eher für Leute die von µCs
> nicht die geringste Ahnung haben und einfach irgendwie irgendwas zum
> laufen kriegen wollen, ohne so richtig zu verstehen was da eigentlich
> los ist. Wer zu Arduino greift weil er einfach nicht löten will hat
> definitiv iwas falsch verstanden.

Mir ging es so mit dem VW New Beetle. Er mag sein wie er will, aber 
niemals ein "neuer Käufer". Er hat nicht mal danebengestanden. Kult wo 
er hingehört. New Beetle fahren ist kein Kult, sondern eine alternative 
Lebenseinstellung, die zu spät kommt. Daher fahren das Ding auch oft 
alte Frauen mit gefärbten Haaren. KLISCHEE /OFF

Trotzdem muss man den Arduino nicht anspucken. Ich verwende das Teil 
auch, um billig und schnell ein paar "Gehversuche" mit einem 
C-programierbaren µC zu machen. Obwohl ich mit anderen Typen zu tun 
hatte (MCS51, PIC, Z80) und die Platinen auch gebaut habe. Aber das ist 
Jahrzehnte her und ich brauchte es dann einfach (beruflich) nicht mehr.

Aktuell will ich "nur" ein (privates) Projekt verwirklichen und muss mir 
nicht mehr beweisen, dass ich Platinen herstellen und einenn µC zum 
Laufen bringen kann. Ich kann es, und das weiß ich. Also hört auf 
(gähn), alle Arduino-Verwender als Dilettanten oder Deppen hinzustellen. 
Das stimmt vlt hier und da, aber jeder hat auch das recht, nur spielen 
zu wollen. Man kann den Spieß ja auch umdrehen. Ein Tiefseetaucher, der 
im Schwimmbad mit seinem Meckern allen auf den Geist geht, dass das 
Dreimeterbecken "nicht tief genug" wäre, ist irgendwie dasselbe in 
Grün....

[Dieter F. (Gast)]

Roth schrieb:
> Man kann den Spieß ja auch umdrehen. Ein Tiefseetaucher, der
> im Schwimmbad mit seinem Meckern allen auf den Geist geht, dass das
> Dreimeterbecken "nicht tief genug" wäre, ist irgendwie dasselbe in
> Grün....

Du bist eindeutig kein Taucher.

[Roth (Gast)]

Der Spiegel schrub im Beitrag #5628706:
> Hat man zufällig ein Multitasking System unter den Fingern (ja, manche
> Arduino Dinger haben das, sind so) stehen die Chancen sehr gut, dass man
> dabei auf die Fresse fällt.
> Mit Karracho.

Du scheinst dich mit diesem "Karracho" ja bestens auszukennen. Bevor du 
in deiner eingefleischten Funktion als Schreibschläger wieder in 
Hormonwallungen und Schweißschüben triggerst, überlege erst. Wenn du das 
überhaupt kannst. Übertrage deine schlimmen Erfahrungen der 
Vergangenheit, die wohl mehr dem Gefrickel denn einem Lernen geschuldet 
sind, nicht auf alle anderen. Nur weil du (ggf. unbewusst) Mitleider 
suchst. Das interessiert hier niemanden. Ich z.B. bin Einsteiger in C. 
Und ich schreibe auch (bei jeder Gelegenheit), dass ich C-Einsteiger 
bin. Ich stelle Fragen, weil ich etwas nicht weiß. Und dann kommt "der 
Spiegel" und haut mir die Fragen um die Ohren und dass ich "zu dumm 
bin", weil ich Fragen stellen ... dazu fällt mir wirklich nichts mehr 
ein außer Kopfschütteln (und ein gewissen Mitleid).

[Roth (Gast)]

Dieter F. schrieb:
> Roth schrieb:
>> Man kann den Spieß ja auch umdrehen. Ein Tiefseetaucher, der
>> im Schwimmbad mit seinem Meckern allen auf den Geist geht, dass das
>> Dreimeterbecken "nicht tief genug" wäre, ist irgendwie dasselbe in
>> Grün....
>
> Du bist eindeutig kein Taucher.

Richtig. Ich bin der, der zum Schwimmen ins Schwimmbad geht. Und nun 
suche die Taucher.

[Dieter F. (Gast)]

Roth schrieb:
> Und nun
> suche die Taucher.

Brauche ich nicht - ich tauche selbst. Aber nicht im Schwimmbad - das 
ist nur für Anfänger (ist das etwa eine Analogie ?).

[Einer K. (Gast)]

Roth schrieb:
> Du scheinst ...
Offensichtlich hast du den Text noch nicht mal im Ansatz erfasst.

[Einer K. (Gast)]

Könnte es sein, dass Verachtung die höchste Form der Anerkennung ist, zu 
der du fähig bist?

Denn, was mich wundert:
Anstatt dankbar zu sein, dass ich dich auf einen Irrtum in deinen 
Überlegungen hingewiesen habe, mühst du dich damit ab den Boten schlecht 
aussehen zu lassen.

[Veit D. (devil-elec)]

Roth schrieb:
> Kannst du den Code "mit millis und Merkern" bitte mal veröffentlichen?
> Das sind ja bestimmt nur ein paar Zeilen. Danke.

Wenn ich den Thread verfolge und du jeden niedermachst der dir über den 
Weg läuft, der dir die Sache über Interrupts richtig erklären möchte, 
dann sehe ich mich nicht gezwungen die nur irgendeinen Codeschnipsel zu 
zeigen.

[Roth (Gast)]

Arduino Fanboy D. schrieb:
> Anstatt dankbar zu sein, dass ich dich auf einen Irrtum in deinen
> Überlegungen hingewiesen habe, mühst du dich damit ab den Boten schlecht
> aussehen zu lassen.

Du kleiner Schreibschläger hast mich auf was hingewiesen? Aha.
Deine kindlichen Fantastereien in Ehren, mit der Keule in der Hand (du 
bist Conan oder?), aber werde bald mal erwachsen.

[Roth (Gast)]

Veit D. schrieb:
> Roth schrieb:
>> Kannst du den Code "mit millis und Merkern" bitte mal veröffentlichen?
>> Das sind ja bestimmt nur ein paar Zeilen. Danke.
>
> Wenn ich den Thread verfolge und du jeden niedermachst der dir über den
> Weg läuft, der dir die Sache über Interrupts richtig erklären möchte,
> dann sehe ich mich nicht gezwungen die nur irgendeinen Codeschnipsel zu
> zeigen.

Auch das ist nicht wahr. Der Arduino Fanboy und sein Gefolge (bzw. 
Handpuppen) sind nicht "jeder". Oder gehörst du auch zu dem Kreis der 
Online Basher? Schade dass solche Schreibschläger sich hier tummeln und 
die Mods dagegen offenbar nichts unternehmen können. Denn die absolut 
überwiegende Mehrheit der Mitglieder sind angenehm und hilfsbereit. Was 
ihr wenigen durch eure Nachstellungen kaputt macht. Stört übrigens nicht 
nur mich und die meisten gehen dann weg. Ich antworte eben, weil ihr das 
am wenigsten ertragen könnt. Feiges, anonymes Schreibschlägerpack!

[Veit D. (devil-elec)]

Hallo,

mal ganz langsam, komme mal wieder runter. Wenn du dich irgendwann 
beruhigt hast wirst du feststellen das wir hier nicht anonym unterwegs 
sind. Zumindestens nicht so anonym wie du. Und wenn du alles mal sacken 
lassen und nicht immer mit der Keule losgehen würdest, dann würdest du 
alle Hilfestellungen hoffentlich anders wahrnehmen und verstehen.

Und wegen "Online Basher". Wenn du so fragst und eine ehrliche Antwort 
erwartest, dann muss ich dir sagen ich sehe nur einen. Und das sind 
nicht die anderen und ich auch nicht.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Roth schrieb im Beitrag #5628958:
> Du bist völlig neben der Kappe und merkst es nicht.
Genug jetzt!