Abstand zwischen zwei Flanken wird nicht korrekt ermittelt

[Klaus (Gast)]

Hallo,

ich verzweifle gerade an einer vermeintlich einfachen Aufgabe: Die Zeit 
zwischen zwei Flanken zu messen! ATmega8a im AS7.

Ich möchte ein digitales Datenprotokoll auswerten, alle ca. 7,5ms kommt 
ein Paket und den Anfang des Pakets möchte ich ermitteln. Das 
Datensignal ist an PD2 (INT0) angeschlossen, der entsprechende INT ist 
auch aktiviert. Zum Test gebe ich den erkannten Beginn des Datenpakets 
über einen Flankenwechsel auf PB3 aus. Soweit zumindest die Theorie. 
Wenn ich in der ISR nur auf die Flankenwechsel schaue und diese nach PB3 
"spiegele", funktioniert es wie gewünscht. Wenn ich aber das Intervall 
zwischen zwei Flanken bestimmen und als Schwellwert für die Erkennung 
eines neuen Datenpakets verwenden möchte, dann klappt das eigentlich 
auch. ABER: In der Berechnung/Abfrage des Intervalls muss irgendetwas 
schief gehen, so dass die Bedingung viel zu häufig erfüllt wird. Das 
Bild vom Oszi ist anbei (Gelb = Datensignal / Rot = Pegel PB3), man 
sieht es wohl recht deutlich, dass PB3 deutlich häufiger umgeschaltet 
wird, als neue Datenpakete anfangen.

Hoffentlich könnt ihr mir helfen! Danke!
Klaus

P.S. Ich hatte zur Probe mal die Intervalldauer per UART ausgeben lassen 
- da hat es wie gewünscht funktioniert! Ich vermute, dass mir eine der 
Compiler-Optimierungen einen Strich durch die Rechnung macht (-Os).

#include <avr/io.h>
#include <avr/interrupt.h>

uint8_t count2us_highByte;
uint16_t count_previous;

uint8_t state;

void init() {

  // Init IO-ports
    DDRB = (1 << PB3);
    PORTB = 0;

    DDRD  = (0 << PD2);      // INT0
    PORTD = (0 << PD2);

    MCUCR = (0 << ISC01)
        | (1 << ISC00);    // Any logical edge on INT0 generates an interrupt request
    GICR = (1 << INT0);      // Enable interrupt on INT0

  // Init timer
  TCCR0 = (0 << CS02)
        | (1 << CS01)
        | (0 << CS00);       // Prescaler 8 --> 2us pro Tick
  TIMSK = (1 << TOIE0);      // Int for OVF

  sei();
}


int main(void) {
  init();
  while(1) { ; }
}

ISR(TIMER0_OVF_vect) { count2us_highByte++; }  // Eigenbau-16Bit-Timer --> HighByte inkrementieren
  
ISR(INT0_vect) {
  uint16_t count;
  uint16_t interval;
  uint8_t tmp_sreg;
  
  tmp_sreg = SREG;
  cli();

  count = TCNT0 + (count2us_highByte << 8);    // Genauen Zeitstempel bestimmen

  interval = count - count_previous;           // Zeitdifferenz zur letzten Flanke bestimmen

  if (interval > 3000) {                       // Wenn mehr als 3000 * 2us, dann Pegel an PB3 umschalten
    if (state) { PORTB &= ~(1 << PB3); }
    else { PORTB |= (1 << PB3); }
    state = 1 - state;
    }

  count_previous = count;                      // Zaehlerstand fuer die naechste Runde speichern

  SREG = tmp_sreg;
}

[Stephan (Gast)]

uint8_t count2us_highByte;
uint16_t count_previous;

Sage dem Compiler mal, dass diese beiden Variablen volatile sind.

VG Stephan

[Klaus (Gast)]

Hallo Stephan,

macht leider keinen Unterschied.

Grüße
Klaus

volatile uint8_t count2us_highByte;
volatile uint16_t count_previous;

[Stephan (Gast)]

Hi Klaus,
Im Einführungstext sagst Du, dass ROT PB3 ist und GELB das Signal... ist 
das korrekt?
VG Stephan

[Klaus (Gast)]

Hallo Stephan,

ist korrekt. Im gelben Signal kommt alle 7,5ms ein Datenpaket und für 
die weitere Auswertung brauche ich den Anfang davon. Zum debuggen habe 
ich diese "Datenpaketanfangserkennung" auf PB3 gelegt, s. rote Kurve.
Es SOLL so funktionieren:
- Speichern des Zeitstempels der letzten Flanke
- Bei einer neuen Flanke die Zeitdifferenz zur vorherigen Flanke merken
- Wenn das mehr als 6000us sind, dann PB3 umschalten

Erwartungshaltung: Ein recht sauberes Rechtecksignal auf PB3 (rot), 
welches den Pegel immer zu Beginn eines Datenpakets wechselt.

Istzustand: S. Screenshot + Frust :)

Viele Grüße
Klaus

[Stefan F. (Gast)]

Klaus schrieb:
> Ich vermute, dass mir eine der
> Compiler-Optimierungen einen Strich durch die Rechnung macht (-Os).

Das lässt sich ja leicht prüfen: stelle auf -O0 um.

[Stephan (Gast)]

count2us_highByte << 8

Kommt da nicht IMMER 0 raus?
count2us_highByte Ist doch uint8_t...
Hmm

VG Stephan

[Stefan F. (Gast)]

Die INT0 hat eine höhere Priorität als der TIMER0_OVF.
Wenn beide Interrupts zeitgleich anliegen, wird daher zuerst INT0 
aufgerufen, so dass deine oberen 8bit von den Pseudo-16bit veraltet und 
somit falsch sind.

[Markus F. (mfro)]

Stephan schrieb:
> count2us_highByte << 8
>
> Kommt da nicht IMMER 0 raus?
> count2us_highByte Ist doch uint8_t...
> Hmm
>
> VG Stephan

Huh?

C-Buch lesen!

[Klaus (Gast)]

Stefan ⛄ F. schrieb:
> Klaus schrieb:
>> Ich vermute, dass mir eine der
>> Compiler-Optimierungen einen Strich durch die Rechnung macht (-Os).
>
> Das lässt sich ja leicht prüfen: stelle auf -O0 um.

Geprüft - macht leider keinen Unterschied.

Stephan schrieb:
> count2us_highByte << 8
>
> Kommt da nicht IMMER 0 raus?
> count2us_highByte Ist doch uint8_t...

Das kriegt der Compiler hin. Zumindest führen

  count = count2us_highByte;
  count = (count << 8);
  count += TCNT0 ;

und

  count = TCNT0 + (uint16_t)(count2us_highByte << 8);

zum gleichen Ergebnis wie der gepostete Code.

Viele Grüße
Klaus

[Klaus (Gast)]

Stefan ⛄ F. schrieb:
> Wenn beide Interrupts zeitgleich anliegen, wird daher zuerst INT0
> aufgerufen, so dass deine oberen 8bit von den Pseudo-16bit veraltet und
> somit falsch sind.

Ich habe jetzt im Timer-INT ebenfalls die anderen Interrupts gesperrt:

ISR(TIMER0_OVF_vect) {
  uint8_t tmp_sreg;
  
  tmp_sreg = SREG;
  cli();

  count2us_highByte++;                    // Eigenbau-16Bit-Timer --> HighByte inkrementieren

  SREG = tmp_sreg;

}

Wirkung sehe ich noch keine. Oder hast du etwas anderes im Sinn? Dann 
bräuchte ich noch einen Tipp von dir.

Grüße
Klaus

[Stefan F. (Gast)]

Stephan schrieb:
> Kommt da nicht IMMER 0 raus?

Das dachte ich auch spontan, geht aber:

volatile uint8_t a;
volatile uint16_t b;

int main(void) 
{
    b=(a<<8);
}

00000090 <main>:
  90:  80 91 02 01   lds  r24, 0x0102  ; das ist Variable a
  94:  90 e0         ldi  r25, 0x00  
  96:  98 2f         mov  r25, r24     ; kopiere  Bit 0-7 nach Bit 8-15
  98:  88 27         eor  r24, r24     ; setze Bit 0-7 auf 0
  9a:  90 93 01 01   sts  0x0101, r25  ; speichern Bit 8-15
  9e:  80 93 00 01   sts  0x0100, r24  ; speichern Bit 0-7
  a2:  80 e0         ldi  r24, 0x00  
  a4:  90 e0         ldi  r25, 0x00  
  a6:  08 95         ret

Weiss jemand, wozu die drei nicht kommentierten ldi Befehle dienen? Mir 
kommen sie unnötig vor.

[Stefan F. (Gast)]

Klaus schrieb:
> Ich habe jetzt im Timer-INT ebenfalls die anderen Interrupts
> gesperrt.
> Wirkung sehe ich noch keine. Oder hast du etwas anderes im Sinn?

Kein Wunder, denn der hat sowieso schon höhere Priorität als der andere. 
Der Punkt ist, dass deine oberen 8 Bit (durch die Overflow ISR) zu spät 
hoch gezählt werden, wenn sich die beiden Interrupts überlappen. Die 
Overflow ISR wird immer erst nach INT0 ausgeführt. Sie muss aber immer 
vorher ausgeführt werden, denn innerhalb der INT0 ISR brauchst du ja den 
aktuellen Zählerstand.

[Andreas M. (amesser)]

cli() in der ISR(INT0_vect) brauchst Du nicht, die Interrupte sind 
innerhalb der ISR eh schon maskiert. Der TCNT0 läuft im Hintergrund 
weiter: Wenn der einen Überlauf hat während du in ISR(INT0_vect) bist, 
dann funktioniert deine Routine nicht. Statt auf den TCNT0 zu schauen, 
müsste doch dein "High-Byte" allein schon ausreichen (3000 / 256) ist 
etwa 12. Bei Längerer Signalpause kann Deine Bedingung übrigens auch mal 
nicht erfüllt sein, wenn man das Fenster trifft.

Ich würde mit einem Timeout arbeiten: Ein globaler Zähler; In 
ISR(INT0_vect) wenn Zähler 0 -> Anfang erkannt, Zähler immer auf 12 
setzen; In ISR(TCNT0_vect) wenn Zähler > 0 -> Zähler--;

[Klaus (Gast)]

Hallo Stefan,

wirklich kritisch wäre das doch vor Allem im Überlauf des 
HighByte-Zählers, der alle 131ms auftritt?

Hast du eine Anregung, wie ich dies auflösen könnte?

Grüße
Klaus

[Stefan F. (Gast)]

Klaus schrieb:
> wirklich kritisch wäre das doch vor Allem im Überlauf des
> HighByte-Zählers, der alle 131ms auftritt?

Das wäre das nächste Problem in der Warteschlange.

> Beitrag "Abstand zwischen zwei Flanken wird nicht korrekt ermittelt"

Guck mal was der Andreas geschrieben hat.

Ich hätte für diese Aufgabe einen 16bit Timer verwendet und den 
Timer-Capture Interrupt.

[Andreas M. (amesser)]

Alternativ könnte man auch ganz ohne den TCNT0_ovf isr arbeiten: Anderen 
Vorteiler wählen so das die 6ms Timeout als Zählwert in den TCNT0 
reinpassen, Timer dauerhaft starten. In ISR(INT0_vect) prüfen ob TCNT0 
Overflow gesetzt ist, wenn ja -> Packet erkannt, TCNT0 mit (0 - 
Zählwert(6ms)) laden und danach Overflow Bit löschen. (Das Overflow Bit 
ist dann der Indikator dafür das 6ms seit der letzten Flanke vergangen 
sind)

[Markus F. (mfro)]

Stefan ⛄ F. schrieb:
> Stephan schrieb:
>> Kommt da nicht IMMER 0 raus?
>
> Das dachte ich auch spontan, geht aber:

Integer promotion.

[S. Landolt (Gast)]

Das mit dem 'count2us_highByte' verstehe ich nicht - muss das nicht 
irgendwann auf 0 gesetzt werden?

[Stefan F. (Gast)]

S. Landolt schrieb:
> as mit dem 'count2us_highByte' verstehe ich nicht - muss das nicht
> irgendwann auf 0 gesetzt werden?

Der läuft von alleine über. Nach 255 kommt 0.

[Klaus (Gast)]

Andreas M. schrieb:
> Statt auf den TCNT0 zu schauen,
> müsste doch dein "High-Byte" allein schon ausreichen (3000 / 256) ist
> etwa 12

Ah, super Idee! Damit kriege ich das hin! Für die Identifizierung des 
Paketbeginns ist das völlig ausreichend. Und das LowByte kann ich für 
die Erkennung der einzelnen Bits nutzen, das passt vom Wertebereich her!

TOP, vielen Dank für eure Hilfe!
Viele Grüße
Klaus

P.S. Ich würde normalerweise auch einen 16-Bit-Timer für die Geschichte 
verwenden. Und auch keinen Atmega8a. Das Projekt ist eine 
Custom-Firmware für ein Spielzeug, daher ist die Hardware vorgegeben. 
Den Timer1 brauche ich für die Generierung von zwei PWM-Signalen, daher 
ist der schon blockiert. Timer2 ist auch belegt. Und Timer0 muss daher 
den Systemtakt und diesen globalen Timer vorgeben.

[Stephan (Gast)]

Markus F. schrieb:
> Integer promotion.

Ach ja, ich vergass.
Danke!

[Peter D. (peda)]

Wie schon gesagt wurde, zähle im Overflow einfach ein Timeout runter 
(Stop bei 0). Im externen Interrupt wird getestet, ob er 0 ist und 
wieder auf die minimle Pausenzeit gesetzt. 7,5ms sind ~14 Überläufe, 
d.h. ein Byte reicht.

Und laß diesen SREG Quatsch sein. Wo hast Du das bloß her?

[A. S. (Gast)]

Wobei mich noch interessieren würde, warum dein erster Code den Fehler 
macht. Die zahlreichen hier gezeigten Probleme erklären den nämlich 
nicht.

Eine Möglichkeit: integral Promotion macht int und nicht uint (ich weiß 
es nicht auswendig).
Nur Highbyte ist natürlich besser, aber interessant wäre es, wenn Du das 
Mal ausprobierst.

[Peter D. (peda)]

A. S. schrieb:
> Wobei mich noch interessieren würde, warum dein erster Code den Fehler
> macht.

Es ist im Prinzip der hier beschriebene Effekt:
Beitrag "AVR Timer mit 32 Bit"

TCNT0 if auf 0 übergelaufen, aber der Overflow noch nicht behandelt, 
d.h. das High-Byte nicht hochgezählt.

[S. Landolt (Gast)]

> Wobei mich noch interessieren würde ...
> ... erklären den nämlich nicht

Vielleicht doch, zumindest teilweise, wenn man berücksichtigt, dass die 
INT0-ISR so um die 25 us benötigt. Ist ein Impuls in dem Datenburst 
kürzer als diese Zeit, wird nach dem Rücksprung aus der INT0-ISR direkt 
wieder hineingesprungen, der Timer-Interrupt hat ja niedrigere 
Priorität. Dann steht also, mit einer gewissen Wahrscheinlichkeit, in 
der INT0-ISR das 'count2us_highByte' noch auf dem alten Wert, TCNT0 ist 
aber kleiner als vorher, und folglich ist 'intervall' negativ bzw. zu 
groß, größer als 3000.

Dasselbe gilt, wenn der Timer-Überlauf zu Beginn der INT0-ISR auftritt, 
nur ist die Wahrscheinlichkeit dafür geringer.

[Kointro (Gast)]

Mag sein, dass C einige Hürden bietet.

Aber schon die Vorgehensweise an allen technischen Möglichkeiten
des zig-fach überdimensionierten mega8 vorbei deutet auf schwere
Orientierungsprobleme in der realen Welt.

Wie wär's mit Vegan-Koch?

[A. S. (Gast)]

S. Landolt schrieb:
> Dann steht also, mit einer gewissen Wahrscheinlichkeit, in
> der INT0-ISR das 'count2us_highByte' noch auf dem alten Wert, TCNT0 ist
> aber kleiner als vorher, und folglich ist 'intervall' negativ bzw. zu
> groß, größer als 3000.

Stimmt, daran hab ich garnicht gedacht. Und mein Ansatz oben war 
natpürlich quatsch, nehm ich zurück. Also: interval int16 (statt 
unsigned) machen.

(ich habe daran nicht gedacht, weil ich sowas wie interval immer signed 
mache.

[Stefan F. (Gast)]

A. S. schrieb:
> Also: interval int16 (statt unsigned) machen.

Du hast es nicht verstanden. Mit negativen Intervallen, wird nichts 
besser. Die Zahlen sind dann immer noch völlig falsch!

[A. S. (Gast)]

Stefan ⛄ F. schrieb:
> Du hast es nicht verstanden. Mit negativen Intervallen, wird nichts
> besser. Die Zahlen sind dann immer noch völlig falsch!

Falsch ja. Aber hier geht es doch nur darum zu schauen, ob es dann 
funktioniert. Und das müsste es, denn der Fehler ist klein, also nicht 
relevant.

Wenn ich mindestens 7 ms will, ist es egal, ob ich auch Mal -1ms habe.

Eine Zeitmessung mit Überlauf-Zähler richtig zu machen ist zwar in 
wenigen Zeilen möglich, aber zum einen nicht einfach und zum anderen vom 
interrupthandling abhängig.

[W.S. (Gast)]

Klaus schrieb:
> ABER: In der Berechnung/Abfrage des Intervalls muss irgendetwas
> schief gehen, so dass die Bedingung viel zu häufig erfüllt wird.

Du erwartest jetzt nicht, daß hier jeder deine gepostete Quelle 
akribisch untersucht, gelle?

Also mal ganz allgemein: du hast vermutlich einfach nur das falsche 
Konzept. Was genau willst du denn feststellen? Den zeitlichen Abstand 
zwischen den einzelnen Impulsen? Oder den zeitlichen Abstand zwischen 
den Bursts? Oder auch noch die Breite der Bursts?

Falls es sich nur um den zeitlichen Abstand zwischen den Anfängen der 
Bursts handelt, dann ist das ein ähnliches Problem wie beim 
Taste-Entprellen.

mein Vorschlag so aus dem Stegreif heraus wäre so:
1. konfiguriere deinen µC so, daß er nur auf die H-->L Flanke einen 
Interrupt auslöst.
2. habe eine Systemuhr in deiner Firmware, die einen Uhrtick von 1 ms 
bis höchstens 2 ms erzeugt.
3. habe in deiner Firmware eine Variable "ABSTAND", ein Flag "PING" und 
ein Byte "PONG"
4. suche dir einen Timer aus, der den Abstand zwischen deinen Bursts für 
deine Belange genau genug zählen kann.
5. in der ISR deines Interrupts machst du folgendes:
5a. setze PING
5b. wenn PONG nicht Null ist, dann beendest du die ISR
5c. wenn PONG Null ist, dann liest du den Timer aus und merkst ihn in 
ABSTAND, setzt den Timer auf 0 und startest ihn wieder. Damit hast du 
den zeitlichen Abstand zum vorherigen Burst in ABSTAND. Nun setzt du 
PONG auf so etwa 2..3 ms (je nach Uhrtick) und beendest die ISR.
6. in der ISR des Uhrticks machst du folgendes:
6a. wenn PING gesetzt ist, setzt du PONG auf 2..3 ms
6b. wenn PING nicht gesetzt ist, und PONG nicht Null ist, zählst du PONG 
um eins herunter.

So, das sollte es gewesen sein. PING zeigt an, daß deine ISR kürzlich 
aktiviert worden ist (quasi Prellen) und die ISR der Uhr sorgt dafür, 
daß PONG nur dann bis 0 dekrementiert wird, wenn wenigstens 2..3 ms am 
Stück kein PING mehr kommt. Dann ist der Burst vorbei und die ISR kann 
auf die nächste gültige Flanke warten.

W.S.

[A. S. (Gast)]

Wenn Interrupts gesperrt:
Überlaufzähler auslesen
Timer auslesen
Wenn interruptflag: nochmal Timer auslesen und Überlaufzähler um 1 
erhöhen (lokal, im originalen Typ)

Wenn tof eine höhere prio hat:
Überlaufzähler auslesen
Timer auslesen
Wenn Überlaufzähler sich geändert hat, Timer nochmals Auslesen

Natürlich immer nur unter der Maßgabe, dass ein Timerüberlauf länger ist 
als der interruptcode.

Aber der TO braucht ja keinen zuverlässigen Code mehr.

[Stefan F. (Gast)]

W.S. schrieb:
> Du erwartest jetzt nicht, daß hier jeder deine gepostete Quelle
> akribisch untersucht, gelle?

Mecker nicht, das ist längst erledigt worden. Die Problemursache wurde 
bereits gestern erkannt und Lösungen empfohlen.

[A. S. (Gast)]

W.S. schrieb:
> Du erwartest jetzt nicht, daß hier jeder deine gepostete Quelle
> akribisch untersucht, gelle?

Der TO hat schon eine Lösung. Und Landolt (und andere) das Problem wohl 
identifiziert.

[Bastler (Gast)]

Man muss einfach den Hardware-Timer zweimal lesen, und dazwischen das 
Timer-Overflow-Flag einmal. Dann kann man Auswerten:

  disableTimerInterrupt();

  uintXX_t softcount = readSoftwareCounter();  

  uint8_t precount = readHardwareCounter()
  bool overflow1 = readOverflowFlag();
  uint8_t hardcount = readHardwareCounter()

  enableTimerInterrupt();

  bool overflow2 = hardcount < precount;

  if (overflow1 || overflow2)
    softcount++;

Und mit hardcount weiter rechnen.

[Peter D. (peda)]

A. S. schrieb:
> Wenn ich mindestens 7 ms will, ist es egal, ob ich auch Mal -1ms habe.

Dann gib mal -1 als unsigned int aus, was siehst Du?

[A. S. (Gast)]

Peter D. schrieb:
> Dann gib mal -1 als unsigned int aus, was siehst Du?

Sag das Stefan

Stefan ⛄ F. schrieb:
> Du hast es nicht verstanden. Mit negativen Intervallen, wird nichts
> besser.

[A. S. (Gast)]

Bastler schrieb:
> Dann kann man Auswerten:

Bzw ist man schon fertig:

  disableTimerInterrupt();

  uintXX_t softcnt = readSoftCnt();  

  uint8_t hardcnt = readHWCnt();
  If(readOverflowFlag())
  {
    hardcnt = readHWCnt();
    softcnt++;
  }
  
  enableTimerInterrupt();

Ohne di wird noch einfacher.

[c-lover (Gast)]

Stefan ⛄ F. schrieb:
> Weiss jemand, wozu die drei nicht kommentierten ldi Befehle dienen? Mir
> kommen sie unnötig vor.

Der 1. erweitert die Variable a nach Integer.
Die beiden letzten liefern als Ergebnis der Funktion "int main()" den 
Wert 0.

[Stefan F. (Gast)]

c-lover schrieb:
> Der 1. erweitert die Variable a nach Integer.
> Die beiden letzten liefern als Ergebnis der Funktion "int main()" den
> Wert 0.

Aha, danke.

[max123 (Gast)]

Hallo,
ich mache derartiges im TIMER-Interrupt.

[/c]

/* Zaehle neg Flanken an PIN 8
 *  mit einem Timerinterrupt.
 *  Also Drahtbrueke von PIN 8 auf GND.
 Drahtbruecke mehrmals herausziehen und wieder einstecken.
 Dadurch zaehlt das Programm die negativen Flanken.
Wird nun von "Seriellen Monitor" (dem Terminal in der Arduino IDE)
ein Zeichen geschickt, wird die Anzahl der neg. Flanken ausgegeben.

 Nicht vergessen: Seriele Baudrate auf 115200 einstellen.
 Das Einlesen eines Zeichens (zur Ausgabe) erfolgt ueber den
 Seriellen Interrupt.
 */
 #include <TimerOne.h>
uint16_t bra,wert;
uint16_t help;
uint16_t alt, differenz,n,anton;
int index;
char inChar;
char ein[20];

void tick()
{ n++;
  bra = digitalRead(8);
  if (bra == 0 && alt == 1 )
    wert ++;  //neg Flanken;

  alt = bra;
}
void setup()
{ pinMode(8, INPUT_PULLUP);
  Timer1.attachInterrupt(tick);
  Timer1.initialize(1000 );    //alle 1ms ein Interrupt
  Serial.begin(115200);        //Baud
  //Serial.println("mit der Seriellen Monitor ein Zeichen senden");
 }
void loop()
{
if(Serial.available() > 1)
   {
 //   Serial.print((long)wert);
 //   Serial.read();
   //  wert = 0;
    }
}

    void serialEvent()     //ISR, wird bei eingehenden Zeichen 
aufgerufen
{
  while (Serial.available() )
  {
    inChar =  (char)Serial.read();
    ein[index++] = (char) inChar;  //eingehende Zeichen werden an String 
gehängt
    index = constrain(index, 0, 19);
    if (inChar == '\n')      //im Terminalproramm unb edingt \n 
anhaengen
    {
      ein [index ] = '\0';     // ein \n schliesst ab
      Serial.println(wert);
      index = 0;
    }
}
}
[/c]