ATmega328 Timer 1 Input capture auf 32 Bit verlängern

[Michael K. (k-mte)]

Hallo Forum,

ich möchte mit einem ATmega328 die 16 Bit Input Capture-Funktion von 
Timer 1 nutzen. Dies geht bei einer Taktfrequenz von 16 MHz bis 2^16 / 
16 MHZ = ca. 4 ms auch ohne Timer 1 Overflow-Interrupts. Bei längeren 
Zeiten muß man die Timer 1 Overflows in die Berechnung der Zeitdauer mit 
einbeziehen.

Das Problem ist, das zwischen dem Auslesen des Capture-Werts von Timer 1 
und dem Auslesen der Überläufe von Timer 1 Zeit vergeht, in der ein 
weiterer Überlauf von Timer 1 stattgefunden haben kann.

Frage: wie löst man dieses Problem technisch sauber?

Ich würde mich über Beispiel-Code freuen.

Viele Grüße

k-mte

[Veit D. (devil-elec)]

Hallo,

wenn man es richtig macht geht nichts verloren. Das zählen erfolgt 
sozusagen "intern" im Hintergrund. Du kannst aller X [ms] oder [s] oder 
[...] den gerade aktuellen Zustand/Wert auslesen.

Stichworte volatile und atomar/atomic.

[Carl D. (jcw2)]

Michael K. schrieb:
> Hallo Forum,
>
> ich möchte mit einem ATmega328 die 16 Bit Input Capture-Funktion von
> Timer 1 nutzen. Dies geht bei einer Taktfrequenz von 16 MHz bis 2^16 /
> 16 MHZ = ca. 4 ms auch ohne Timer 1 Overflow-Interrupts. Bei längeren
> Zeiten muß man die Timer 1 Overflows in die Berechnung der Zeitdauer mit
> einbeziehen.
>
> Das Problem ist, das zwischen dem Auslesen des Capture-Werts von Timer 1
> und dem Auslesen der Überläufe von Timer 1 Zeit vergeht, in der ein
> weiterer Überlauf von Timer 1 stattgefunden haben kann.

Wenn die Timer1-Capture-ISR verwendet wird, dann kann der 
Timer1-Overflow gar nichts anstellen, da er niedrigere Prio hat. Solange 
man in der Capture-ISR nicht vor dem Lesen von Capture-Register und 
Overflow-Variable die Interrupts wieder freigibt (und falls du fragen 
würdest, wie das geht, ist das unwahrscheinlich), dann kann nichts 
passieren.

Ohne Capture-ISR, also z.B. in der Main-/Arduino-Loop, sollte man 
ICP1-Wert und TCNT1-Wert vergleichen, ist letzterer kleiner, dann hat 
man einen Überlauf zu viel gezählt.

> Frage: wie löst man dieses Problem technisch sauber?
>
> Ich würde mich über Beispiel-Code freuen.
>
> Viele Grüße
>
> k-mte

[S. Landolt (Gast)]

> ein weiterer Überlauf von Timer 1

Der steht dann ja im (nicht gelöschten) TIFR1.TOV1.

[Oliver S. (oliverso)]

Michael K. schrieb:
> Das Problem ist, das zwischen dem Auslesen des Capture-Werts von Timer 1
> und dem Auslesen der Überläufe von Timer 1 Zeit vergeht, in der ein
> weiterer Überlauf von Timer 1 stattgefunden haben kann.

Auf das Capture-Flag in der OVF-ISR prüfen. Wenn das da gesetzt ist, ist 
das der Hinweis dafür, daß der zu zählende Überlauf entweder 
gleichzeitig mit dem (dann ist der Capture-Wert entweder MAX oder 
BOTTOM, je nach Zählerbetriebsart) oder nach dem Capture-Event 
stattgefunden hat.

Oliver

[Thomas E. (thomase)]

Michael K. schrieb:
> Frage: wie löst man dieses Problem technisch sauber?

Stell den Prescaler so ein, daß es in einem Umlauf passt. Wozu brauchst 
du bei solch einer Langzeitmessung eine Auflösung von 62,5ns?

[Sebastian S. (amateur)]

>Michael K. schrieb:
>> Frage: wie löst man dieses Problem technisch sauber?

>Stell den Prescaler so ein, daß es in einem Umlauf passt. Wozu brauchst
>du bei solch einer Langzeitmessung eine Auflösung von 62,5ns?

@Thomas E.
Merke:
In sehr vielen Posts hier im Forum kann man sehen, dass z. B. bei großen 
Öfen 1000 mal pro Sekunde die Temperatur abgefragt wird und der 
zugehörige Regler damit gefüttert wird, der Pegel in einem großen 
Wasserbecken, via Ultraschall (Kann man das nicht mit einem Laser noch 
schneller machen?), so schnell wie möglich abgefragt wird und die 
Motorposition eines tonnenschweren Teils 50000 mal pro Sekunde ermittelt 
wird.
Oft mit dem Ende vom Lied: Ich brauche einen schnelleren Prozessor!

[Thomas E. (thomase)]

Sebastian S. schrieb:
> @Thomas E.
> Merke:

Ich werd's mir hinter die Ohren schreiben.

[S. Landolt (Gast)]

an Michael K.:

Ich sehe es so: in der ICP-ISR stellt sich die Frage, ob ein noch nicht 
gezählter Timer-Overflow stattgefunden hat. Dazu prüft man das TOV-Flag: 
ist es gesetzt, muss noch festgestellt werden, wann das geschah, ob vor 
oder nach dem ICP: liegt der ICR-Wert knapp unter TOP, wird der 
Overflow verworfen, liegt er knapp über BOTTOM, muss der Overflow 
hinzuaddiert werden.

[m.n. (Gast)]

Michael K. schrieb:
> Ich würde mich über Beispiel-Code freuen.

// Routinen zur Erfassung der Eingangsimpulse
// Ueberlaeufe von T1
ISR(TIM1_OVF_vect)            
{
  ueberlauf++;                            // Ueberlaeufe von T1 ergeben obere 16bit der Messzeit
}

// CAPT-Ereignisse an AIN1
ISR(TIM1_CAPT_vect)                       // Eingangsimpulse mit genauem Zeitpunkt erfassen
{
static unsigned long count;               // Impulse per Interrupt                
  count++;
  if(mess_status == AUSLESEN) {           // Ergebnisse synchron zum Eingangsimpuls auslesen+ablegen
    end_ereignis = count;                 // Anzahl der Impulse lesen
    zeit_low = ICR1;                      // capture-reg lesen: untere 16bit
    zeit_high = ueberlauf;                // dazu die oberen 16bit
    if((TIFR1 & BIT(TOV1)) && 
      (zeit_low < T1_MAX/2))              // evtl. Ueberlauf T1 noch offen?
      zeit_high++;                        // nur, wenn capture-int + overflow-int gleichzeitig !
    mess_status = AUSWERTEN;              // Daten fertig fuer Auswertung
  }
}

[Michael K. (k-mte)]

Hallo Forum,

ich habe mittlerweile ein avr-gcc-Programm erstellt, das mittels Input 
Capture die Timer 1-Ticks zwischen zwei steigenden Flanken eines 
TTL-Signals zählt, das an Pin ICP1 (= Pin 14) eines ATmega328P anliegt. 
Wenn dort eine Frequenz von 1 Hz einspeise, werden wie erwartet 16 Mio. 
Ticks gezählt. Das Programm scheint also zu funktionieren. Ich würde 
mich freuen, wenn dennoch einmal erfahrene Forumsmitglieder den Code 
anschauen und auf offensichtliche Fehler überprüfen könnten, damit 
jemand, die diesen Code möglicherweise in Zukunft einmal kopiert, keine 
Probleme damit bekommt.

Vielen Dank!

MfG

k-mte

#include <stdio.h>
#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

#define BAUD 38400UL

#define MYUBRR (((F_CPU + BAUD * 8LU) / (BAUD * 16LU) - 1LU))

static FILE mystdout = { 0 };

volatile unsigned long t1_ticks = 0;

volatile unsigned char flag = 0;

/********************************************************************************/

static int uart_putchar (char c, FILE *stream)
  {
  while ( !( UCSR0A & (1<<UDRE0)) )
    ;

  UDR0 = c;

  return 0;
  }

/********************************************************************************/

void uart_init (void)
  {
  DDRD |= 0b10000000;

  UBRR0H = (unsigned char) (MYUBRR >> 8);

  UBRR0L = (unsigned char) (MYUBRR & 0xFF);

  UCSR0B = (1<<RXEN0) | (1<<TXEN0);

  UCSR0C = (3 << UCSZ00);

  fdev_setup_stream (&mystdout, uart_putchar, NULL, _FDEV_SETUP_WRITE);

  stdout = &mystdout;
  }

/********************************************************************************/

ISR (TIMER1_OVF_vect)
  {
  t1_ticks += 0x10000;
  }

/********************************************************************************/

ISR (TIMER1_CAPT_vect)
  {
  unsigned char sreg = SREG;

  unsigned int icr1;

  cli ();

  icr1 = ICR1;

  if ((TIFR1 & (1<<TOV1)) && (icr1 < 0x8000))
    t1_ticks += 0x10000;

  t1_ticks += (unsigned long) icr1;

  flag = 1;

  SREG = sreg;
  }

/********************************************************************************/

void t1_init (void)
  {
  /** Input capture Pin ICP1 (Pin 14) = Eingang **/

  DDRB &= 0b11111110;

  /** PRR – Power Reduction Register (S. 54) **/

  PRR &= 0b11110111;

  /** TCCR1A – Timer/Counter1 Control Register A (S. 140) **/

  TCCR1A = 0;

  /** TCCR1B – Timer/Counter1 Control Register B (S. 142) **/

  TCCR1B = 0b11000001;

  /** TIMSK1 – Timer/Counter1 Interrupt Mask Register (S. 144) **/

  TIMSK1 = 0b00100001;

  /*** TIFR1 – Timer/Counter1 Interrupt Flag Register (S. 145) **/

  TIFR1 &= 0b00100111;

  /** Interrupts global ein **/

  sei ();

  }

/********************************************************************************/

int main (void)
  {
  uart_init ();

  t1_init ();

  while (1)
    {
    while (flag == 0)
      ;

    printf ("%lu\r\n", t1_ticks);

    t1_ticks = 0;

    flag = 0;
    }

  return 0;
  }

[Fachlaie (Gast)]

Michael K. schrieb:
> TCCR1B = 0b11000001;

Ich liiieeeebe diese Magic Numbers.

Es gibt doch nichts schöneres als Rätsel zu lösen in denen
ein Rätsel versteckt ist.

[weg mit dem Troll - subito (Gast)]

Ich verwende eine variable  "byte overflowcount"

Welcher beim Initialisieren auf Null gesetzt wird. Der overflow 
interrupr incrementiert diesen wert. Und beim naechsten capture wird zur 
Endzeit die 65536 * overflowcount hinzugezehlt.

[Michael K. (k-mte)]

ACHTUNG, FEHLER IN DER ZIP-DATEI!

In der zip-Datei heißt es:

  if ((TIFR1 & (1<<TOV1)) && (icr1 < 0x8000))
    t1_ticks += 0x1000;

Richtig müßte es heißen:

  if ((TIFR1 & (1<<TOV1)) && (icr1 < 0x8000))
    t1_ticks += 0x10000;

(Konstante ist in der zip-Datei fälschlicherweise 0x1000 statt 0x10000)

Sorry!

k-mte

[Fachlaie (Gast)]

Michael K. schrieb:
> Sorry!

Dass du hier die geneigten Interessenten mit (Aufforderungen
zum Datenblatt lesen) Rätseln bzw. Magic Numbers beaufschlagst
tut dir nicht leid?

[Peter D. (peda)]

Michael K. schrieb:
> Frage: wie löst man dieses Problem technisch sauber?
>
> Ich würde mich über Beispiel-Code freuen.

Bitte sehr:

Beitrag "AVR Timer mit 32 Bit"

[m.n. (Gast)]

Peter D. schrieb:
> Bitte sehr:

Danke, nein.
Zum einen kein Capture, zum anderen (verlangsamender) Prescaler 
aktiviert und zum 3. get_ticks() muß zyklisch aufgerufen werden, damit 
Überläufe von t2_soft wahrgenommen werden.

Michael K. schrieb:
> cli ();

Was soll das?

> ISR (TIMER1_OVF_vect)
>   {
>   t1_ticks += 0x10000;
>   }

Auf einem 8-Bitter eher ungeschickt, 0x10000 zu addieren. += 1 reicht 
aus.

[Hans-jürgen H. (hjherbert)]

Wir merken uns Global:


#define u32 unsigned long
#define u16 unsigned short
#define u16 unsigned char


u16 lastcnt1 ;       // Der zuletzt gelesene Wert
u16 actcnt1 ;      // Der jetzt aktuelle Wert
u16 countextender ;




Und wenn ich den Wert brauche, rufe ich dieses Unterprogramm:

FUNCT u32 gettick( void )                               // AVR
{
u8 oldstat ;
union {
        u32 ul ;
        struct {
                u16 lw ;
                u16 hw ;
                } w ;
        } retval ;
oldstat = SREG ;


cli();      // Interrupt ausschalten

actcnt1 = TCNT1 ;       // Den 16-Bit-Wert von das Hardware ( 2MHz )
if ( actcnt1 < lastcnt1 )
        {               // Einmal pro 65536 * 0.5 us Einmal alle 32768 
us
        ++countextender ;
        }
retval.w.lw = lastcnt1 = actcnt1 ;
retval.w.hw = countextender ;
SREG = oldstat ;
return retval.ul ;
}

Wenn ich dieses Unterprogramm gettick() in der Haupt-Arbeitsschleife 
garantiert alle 32768 us aufrufe, brauche ich keinen Interrupt.

Ansonsten muss in der Interrupt-Routine das gemacht werden:


cli();      // Interrupt ausschalten

actcnt1 = TCNT1 ;       // Den 16-Bit-Wert von das Hardware ( 2MHz )
if ( actcnt1 < lastcnt1 )
        {               // Einmal pro 65536 * 0.5 us Einmal alle 32768 
us
        ++countextender ;
        }
SREG = oldstat ;




Initialisiert wird T1 so:

// Einrichten des Zeitgebers
FUNCT inline void tickopen(void)    // #ifdef AVR
{
// Alle Atmel AVR Mikrocontroller
TCCR1A = 0 ;           // Bit 7,6 : no connection to output line
                       // Bit 1,0 : no PWM operation
TCCR1B = AVR_TIMER_DIVIDER_CODE ;       //
                       // Bit 7 : 0 = No Input noise capture
                       // Bit 6 : Edge Select
                       // Bit 3 : 0 = No Clear on compare
                       // Bit 2,1,0 : 000 = Stopped
                       //                         001 = CK/1
                       //                         010 = CK/8
                       //                         011 = CK/64 <<<
                       //                         100 = CK/256
                       //                         101 = CK/1024
                       //                         110 = extern H-L
                       //                         111 = extern L_H
}


Das Umrechnen von Verzögerungszeiten in Ticks geht durch das Makro:


#define sectotickx( secs ) (u32)( (secs) * tickpersec + 0.49999900 )

Der dafür benötigte Wert tickpersec ist fest, wird also schon vom 
Compiler berechnet:


#ifndef AVR_TIMER_DIVIDER
#if AVR_TIMER_DIVIDER_CODE == 1
#define AVR_TIMER_DIVIDER 1L
#elif AVR_TIMER_DIVIDER_CODE == 2
#define AVR_TIMER_DIVIDER 8L
#elif AVR_TIMER_DIVIDER_CODE == 3
#define AVR_TIMER_DIVIDER 64L
#elif AVR_TIMER_DIVIDER_CODE == 4
#define AVR_TIMER_DIVIDER 256L
#elif AVR_TIMER_DIVIDER_CODE == 5
#define AVR_TIMER_DIVIDER 1024L
#endif
#endif

#define tickpersec ((double)(F_CPU)/(double)AVR_TIMER_DIVIDER)  // 
20000000/8=2500000


Und das ganze habe ich so ähnlich nochmal für TurboC++ und DOS, um die 
Steuerung (oder Teile) im PC vortesten zu können.
Aber da stattdessen

#define tickpersec 1193180.0

struct stickuchars {
        u8 ucl ;
        u8 uch ;
        u16 uwh ; } ;
struct stickuwords {
        u16 uwl ;
        u16 uwh ; } ;
struct stickulongs {
        u32 ull ;
        } ;

union uticks {
        struct stickulongs ul ;
        struct stickuwords uw ;
        struct stickuchars uc ;
                } ;

u16 far * const tick_in_dos_page_46 = (u16 far *)0x0000046C ;
u16 far * const hitick_in_dos_page_46 = (u16 far *)0x0000046E ;


#define ul_mod_tick_in_dos_page_46      (*(u32 far *)0x0000046C)
// #endif
// ... continued #if defined( BORDOS ) || defined( DOSGNU )

static union uticks pre ;
static union uticks post ;
static u16 olddistick ;

FUNCT inline void tickopen( void )
{
disable();
outportb( 0x43, 0x34 );
// 0x34 = 0b00110100
//          00           Select Counter 0
//            11         Reload timer lsb msb
//              010      Mode 2 Rate Generator
//                 0     Binary, not BCD
outportb( 0x40, 255 );  // Low Timer Value
outportb( 0x40, 255 );  // High Timer Value
enable();
}


// Warning : After Midnight the cell 46c will be reset to 0 !
// this is not handled in this program
FUNCT inline u32 gettick( void )
{

disable_int();                      // Interrupt off

#if defined( BORDOS ) || defined(MDOS10) || defined(MSVC10)
pre.uw.uwh = *tick_in_dos_page_46 ;
#elif defined(DOSGNU)   // DOSGNU = DJGPP
pre.uw.uwh = _farnspeekw( 0x0000046C ) ;
#elif defined(WATCOM)
pre.uw.uwh = *(u16 *)0x0000046C ;
#endif


outportb( 0x43, 0 );    // Latch counter
pre.uc.ucl = inportb( 0x40 );
pre.uc.uch = inportb( 0x40 );
enable_int();                       // interrupt on

#if defined( BORDOS )  || defined(MDOS10) || defined(MSVC10)
post.uw.uwh = *tick_in_dos_page_46 ;
#elif defined(DOSGNU)   // DOSGNU = DJGPP
post.uw.uwh = _farnspeekw( 0x0000046C ) ;
#elif defined(WATCOM)
post.uw.uwh = *(u16 *)0x0000046C ;
#endif

if ( pre.uw.uwh != post.uw.uwh )
        {    // Der Timer-Interrupt kam dazwischen.
        post.uw.uwl = 0 ;  // Dann gehoert der Timer-Wert 0 dazu
        return post.ul.ull ;
        }
pre.uw.uwl = ~pre.uw.uwl ;
return pre.ul.ull ;
}

[m.n. (Gast)]

Hans-jürgen H. schrieb:
> post.uw.uwh = _farnspeekw( 0x0000046C ) ;

Cool, genau das hat der TO gesucht!
Davor zur Sicherheit noch 2 x cli(); damit auch garnichts mehr schief 
gehen kann :-(

[Peter D. (peda)]

m.n. schrieb:
> Zum einen kein Capture, zum anderen (verlangsamender) Prescaler
> aktiviert und zum 3. get_ticks() muß zyklisch aufgerufen werden, damit
> Überläufe von t2_soft wahrgenommen werden.

Stellst Du Dich absichtlich dumm?
Ob Polling oder Interrupt, ob mit oder ohne Prescaler, ob 8 oder 
16Bit-Timer spielt überhaupt keine Geige. Das Prinzip bleibt immer das 
gleiche.

[m.n. (Gast)]

Das Prinzip war doch schon längst geklärt.
Die konkrete Frage des TO bezieht sich auf T1 Input Capture.
Auch zu Karneval kann daher die Kiste mit den ollen Kamellen ruhig 
geschlossen bleiben.

[S. Landolt (Gast)]

> ... wie erwartet 16 Mio. Ticks gezählt ...

Bei dem gezeigten Hauptprogramm eine gewagte Aussage - wie lange müsste 
man da vor dem Controllterminal sitzen, um den seltenen Sonderfall zu 
beobachten?
  Ins Hauptprogramm gehört ein interruptgesperrter Teil mit 65536/2 
minus, sagen wir mal, zehn Prozent Takten.

[Michael K. (k-mte)]

Hallo Forum,

das Programm enthält noch einen Fehler. Ich setze (in "main") zwar 
"t1_ticks" zurück, nicht aber "icr1" - was auch gar nicht möglich ist, 
da T1  ein freilaufender Zähler ist.

Lösung: "t1_ticks" nicht zurücksetzen, somit eine "absolute Zeit" 
ermitteln und die Zeitdifferenz dann durch Subtraktion des letzten 
Meßwerts vom aktuellen Wert bilden.

[Michael K. (k-mte)]

Das Gefühl, ja die Gewißheit, dass in meinem Programm irgendwie der Wurm 
drin ist, führt dazu, dass es mich immer noch beschäftigt. Hier nun 
meine Überlegungen:


1. Grundlagen (in stark vereinfachter Darstellung)

Bei einem Hardware-Reset wird T1 gelöscht.

Beim Capture-Betrieb wird ein UND so vor T1 geschalten, dass T1 
hochzählt,
solange der Capture-Eingang ICP1 High ist. Bei einer negativen Flanke an
ICP1 wird der Zählerstand ins Capture-Register übernommen. Solange an 
ICP1
ein L-Pegel anliegt, zählt der Zähler nicht weiter. Wenn nach einer 
steigenden Flanke an ICP1 wieder ein H-Pegel anliegt, zählt T1 von dem 
Zählerstand aus weiter, bei dem er nach der fallenden Flanke 
stehengeblieben war.

Im folgenden wird davon ausgegangen, dass der Zählerstand des 
Capture-Registers und des Overflow-Zählers im Capture-Interrupt 
ausgelesen werden.


2. Normalbetrieb

Der Overflow-Interrupt tritt bei einem Zählerüberlauf auf (also umgefähr 
bei einem Zählerstand von 0), der Capture-Interrrupt trete bei einem 
Zählerstand von umgefähr 32.768 auf.

Beide Interrupts interferieren nicht.


3. Overflow-Interrupt im Anschluß an den Capture-Interrupt

Nun lassen wir den Capture-Interrupt immer später auftreten, schließlich 
bei einem Zählerstand von 65.535. Dies führt dazu, dass zuerst der 
höherpriore Capture-Interrupt vollständig abgearbeitet wird und im 
Anschluß daran der niederpriore Overflow-Interrupt.

Beide Interrupts interferieren nicht.


4. Capture- und Overflow-Interrupt gleichzeitig

Falls der Capture-Interrupt noch etwas später, bei einem Zählerstand von 
0
auftritt, tritt er gleichzeitig mit dem Overflow-Interrupt auf. Dies hat 
zur Folge, dass ein T1-Überlauf stattgefunden hat, ohne dass der 
Overflow-Interrupt in der Lage gewesen wäre, inzwischen den 
Overflow-Zähler hochzuzählen.

Bei der Ermittlung des Zeitpunkts ist diese Konstellation (falls 
möglich) zu detektieren und ein in der Zukunft stattfindender 
Overflow-Interrupt vorwegzunehmen. Da dieser Overflow-Interrupt den 
Overflow-Zähler nach Beendigung des Capture-Interrupts aber noch 
hochzählen wird, darf der Overflow-Zähler aber nicht wie im Beispiel von 
Peter Danegger zusätzlich im Capture-Interrupt hochgezählt werden.


5. Capture-Interrupt tritt während eines Overflow-Interrupt auf

Falls der Capture-Interrupt noch etwas später auftritt, ist inzwischen 
ein
Overflow-Interrupt eingetreten. Dabei gibt es zwei Möglichkeiten.


5.1 Overflow-Interrupt wird vor dem Hochzählen des Overflow-Zählers
    unterbrochen

Dann gilt das unter 4 gesagte.


5.2 Overflow-Interrupt wird während des Hochzählens des Overflow-Zählers
    unterbrochen

Wenn der Overflow-Interrupt unterbrochen wird, während die einzelnen 
Bytes
des Overflow-Zählers vom Typ unsigned int inkrementiert werden, hat dies 
zur Folge, dass im Capture-Interrupt beim Auslesen des Overflow-Zählers 
Mist rauskommt.


5.3 Overflow-Interrupt wird nach dem Hochzählen des Overflow-Zählers
    unterbrochen

Der im Capture-Interrupt ausgelesene Overflow-Zähler wird korrekt 
ausgelesen.


Fazit:

Vor dem Hintergrund des oben gesagten habe ich meine Zweifel, ob das von 
mir angesprochene Problem eines per Software auf 32 Bit verlängerten 
Input Captures bei einem ATmega328 überhaupt lösbar ist, geschweige denn 
technisch sauber. Insofern stehe ich dem im folgenden veröffentlichten 
Code ziemlich skeptisch gegenüber, zumal es mir mit dem mir zur 
Verfügung Stehenden bislang nicht gelungen ist, einen Problemfall zu 
generieren.

/** Globale Variablen **/

volatile unsigned long int t1_overflow = 0;

volatile unsigned long int temp_t1_overflow;

volatile unsigned int temp_icr1;

volatile unsigned char problem;

volatile unsigned char flag = 0;

/** Overflow-Interrupt **/

ISR (TIMER1_OVF_vect)
  {
  t1_overflow++;
  }

/** Capture-Interrupt **/

ISR (TIMER1_CAPT_vect)
  {
  unsigned char sreg = SREG;

  cli ();

  if ((TIFR1 & (1<<TOV1)) && (ICR1 < 0x8000))
      problem = 1;
    else  problem = 0;

  temp_t1_overflow = t1_overflow;

  temp_icr1 = ICR1;

  flag = 1;

  SREG = sreg;
  }

/** Hauptprogramm **/

void capture (void)
  {
  unsigned long int neuer_wert, alter_wert = 0;

  uart_init ();

  t1_init ();

  while (1)
    {
    while (flag == 0)
      ;

    neuer_wert = ((unsigned long) temp_icr1) + (temp_t1_overflow << 16);

    if (problem == 1)
        {
        neuer_wert += (unsigned long) 0x10000;

        printf ("* ");
        }
      else  {
        printf ("  ");
        }

    printf ("%10li\r\n", (unsigned long int) neuer_wert - (unsigned long int) alter_wert);

    alter_wert = neuer_wert;

    flag = 0;
    }
  }

[Oliver S. (oliverso)]

Michael K. schrieb:
> Beim Capture-Betrieb wird ein UND so vor T1 geschalten, dass T1
> hochzählt,
> solange der Capture-Eingang ICP1 High ist. Bei einer negativen Flanke an
> ICP1 wird der Zählerstand ins Capture-Register übernommen. Solange an
> ICP1
> ein L-Pegel anliegt, zählt der Zähler nicht weiter. Wenn nach einer
> steigenden Flanke an ICP1 wieder ein H-Pegel anliegt, zählt T1 von dem
> Zählerstand aus weiter, bei dem er nach der fallenden Flanke
> stehengeblieben war.

Davon ist das allermeiste falsch. RTFM.

Oliver

[Peter D. (peda)]

Michael K. schrieb:
> Beim Capture-Betrieb wird ein UND so vor T1 geschalten, dass T1
> hochzählt,
> solange der Capture-Eingang ICP1 High ist.

Wozu soll das gut sein?
Was willst Du damit erreichen?

[Rainer V. (a_zip)]

Michael K. schrieb:
> Vor dem Hintergrund des oben gesagten habe ich meine Zweifel, ob das von
> mir angesprochene Problem eines per Software auf 32 Bit verlängerten
> Input Captures bei einem ATmega328 überhaupt lösbar ist, geschweige denn
> technisch sauber. Insofern stehe ich dem im folgenden veröffentlichten
> Code ziemlich skeptisch gegenüber, zumal es mir mit dem mir zur
> Verfügung Stehenden bislang nicht gelungen ist, einen Problemfall zu
> generieren.

Also bitte, du hast doch alles bekommen, was du brauchst. Was willste 
denn an dem simplen Konstrukt jetzt überhaupt noch austesten?? Und dann 
auch noch technisch sauber...manohman. Es drängt sich mir der Verdacht 
auf, dass du einfach nicht verstanden hast, was das Beispielprogramm 
macht und dann ist es natürlich nicht so einfach, einen "Problemfall" zu 
generieren :-)
Gruß Rainer

[Michael K. (k-mte)]

Hallo Forum,

anbei habe ich die letzte Version meines Programms hochgeladen.