Timer1 ISR - kein festes zeitverhalten

[Adam P. (adamap)]

hallo zusammen,

ich habe seit gestern ein problem mit meinem timer1 (atmega 1284p).
zuerst meine konfig:

#define CLK_PRELOAD_10MS     2499L

void sys_clk_init(void)
{
    /* Compare Match */
    TCCR1A = 0;
    TCCR1B |= (1<<WGM12) | (1<<CS11) | (1<<CS10);
    OCR1A = CLK_PRELOAD_10MS;
    TIMSK1 |= (1<<OCIE1A);
}

die ISR vom timer löst jede 10ms aus, soweit so gut. in der ISR erhöhe 
ich eine variable ticks vom typ uint32_t.
diese lasse ich mir in der main(), jede sekunde ausgeben - die ausgabe 
ist dann:

100
200
300
400
...usw.

nun bekomme ich ein fehlverhalten bei festen zeiten, was mir nicht so 
ganz einleuchtet.
z.b. von dem wert 9300 auf 9316. egal wie oft ich die steuerung neu 
starte, der fehler tritt immer an den gleichen stellen auf...auch im 
späteren verlauf.

meine main():

int main(void)
{
    init();
  
    char num[7];
  
    DDRA = 0xff;
    DDRD = 0xff;
  
    uint32_t tick = get_uptime(TICKS) + 100;
  
    while(1)
    {
        if(tick <= get_uptime(TICKS))
        {
            tick = get_uptime(TICKS) + 100;
            PORTA ^= (1<<PINA0);
            PORTD ^= (1<<PIND5);
      
            ultoa( (tick), num, 10);
            uart_puts(num);
            uart_putc(10);
            uart_putc(13);
        }
    }
    return 0;
}

ist im moment nur eine testausgabe, hoffe nicht das der fehler in der 
abfrage der ticks liegt, dass er dort zu früh/spät abfragt und einen 
falschen wert erkennt. die andere möglichkeit was mir noch einfällt 
könnte der vorladewert des timers sein?!

hoffe ihr habt eine idee.

gruß adam

[Karl H. (kbuchegg)]

Adam P. schrieb:

> die ISR vom timer löst jede 10ms aus, soweit so gut. in der ISR erhöhe
> ich eine variable ticks vom typ uint32_t.

Und die ist hoffentlich volatile und und die Ausleseanweisung ist mit 
einem cli()/sei() gekapselt, zwecks atomarem Zugriff.

[Peter D. (peda)]

Adam P. schrieb:
> hoffe nicht das der fehler in der
> abfrage der ticks liegt

Hoffen und Harren macht manchen zum Narren.

Immer diese Zumutung, nur durch Schlüsselloch gucken zu dürfen.
Mach die Tür auf und zeig alles (als Anhang)!

Peter

[Adam P. (adamap)]

Karl Heinz Buchegger schrieb:
> Und die ist hoffentlich volatile und und die Ausleseanweisung ist mit
> einem cli()/sei() gekapselt, zwecks atomarem Zugriff.

du meinst die tick variable? wie du siehst ist die in main nicht 
volatile.
den wert den ich erhöhe wird in einem array abgelegt das diverse daten 
enthält, die fkt. get_uptime liest dann von dem index x aus dem array 
den wert, den die ISR erhöht.

also wenn ich nun in der main z.b. cli()/sei() einbaue, dann sollte es 
gut sein? aber damit halte ich doch die abarbeitung der ISR auf und habe 
somit doch im laufe der zeit eine zeitverschiebung oder?

[Karl H. (kbuchegg)]

Adam P. schrieb:
> Karl Heinz Buchegger schrieb:
>> Und die ist hoffentlich volatile und und die Ausleseanweisung ist mit
>> einem cli()/sei() gekapselt, zwecks atomarem Zugriff.
>
> du meinst die tick variable?

Nö.
Wie kommt get_uptime(TICKS) zu seinen Erkentnissen?

Dort wird ja wohl die Variable in irgendeiner Form ausgewertet, die von 
der ISR hochgezählt wird.

> wie du siehst ist die in main nicht
> volatile.
Ich sehe nur, dass du die relevanten Dinge wieder mal nicht zeigst, zu 
gunsten von Dingen die eh keinen interessieren. Dass du ein ultoa 
fehlerfrei hinkriegst, davon sollte man eigentlich ausgehen können.

> den wert den ich erhöhe wird in einem array abgelegt das diverse daten
> enthält, die fkt. get_uptime liest dann von dem index x aus dem array
> den wert, den die ISR erhöht.

Ach.
Da gibt es also noch zusätzlich jede Menge anderes Zeug, dass du 
verbockt haben könntest?

Nur gut, dass du uns das alles gezeigt hast!
Oops. Hast du ja gar nicht.

[Adam P. (adamap)]

...ein moment, bitte :)

p.s. ich habe kein problem euch das zu zeigen, es hätte nur sein können, 
dass jemand eine spontane idee hätte.

[Karl H. (kbuchegg)]

uint32_t get_uptime(uint8_t format)
{
  cli();   // *********  <--------------------


  switch(format)
  {
  case TICKS:
      return reg_read32(SYS_TICKS);
    break;

  case SECOND:
      return reg_read32(UPTIME_SS);
    break;

  case MINUTE:
      return reg_read32(UPTIME_MM);
    break;

  case HOUR:
      return (uint32_t)(reg_read(UPTIME_HH));
    break;

  case DAY:
      return (uint32_t)(reg_read(UPTIME_DD));
    break;
    
  default:
      return 0;
    break;
  }

  sei();   // ***********   <---------------------
}

mal als Erstabhilfe. Ob sonst nach was im argen liegt hab ich jetzt 
nicht kontrolliert.

[Adam P. (adamap)]

ok, vielen dank! werde ich direkt mal ausprobieren.

bekomme ich denn dadurch keine zeitverschiebung in meinem 10ms takt?
falls die ISR genau in diesem moment den wert erhöhen möchte.

falls doch, welche möglichkeiten gäbe es dieses problem zu umgehen?
bin für jede anregung dankbar!

[Karl H. (kbuchegg)]

Adam P. schrieb:
> ok, vielen dank! werde ich direkt mal ausprobieren.
>
> bekomme ich denn dadurch keine zeitverschiebung in meinem 10ms takt?
> falls die ISR genau in diesem moment den wert erhöhen möchte.

Dann findet das Erhöhen halt um ein paar µs später statt und beim 
nächsten ISR Aufruf stimmts dann wieder.

Nur weil Interrupts mittels cli() gesperrt sind, bedeutet das ja nicht, 
dass Interrupts automatisch unterschlagen werden. Die ISR wird dann eben 
erst zum Zeitpunkt aufgerufen, an dem mittels sei() die Interrupts 
wieder freigegeben werden. Und da der Timer in der Zwischenzeit 
unbeeindruckt weitergezählt hat, kommt der nächste Interrupt dann auch 
wieder pünktlich.

> falls doch, welche möglichkeiten gäbe es dieses problem zu umgehen?

Bissi lernen, wie die Dinge wirklich funktionieren.

[Adam P. (adamap)]

vielen danke karl heinz!

ist ja nicht so das ich erst seit gestern µc programmieren, aber 
manchmal steh ich da und seh den wald vor lauter bäumen nicht mehr.

aber das mit dem sperren ist ja irgendwie klar beim lesen, da ich 
mehrere 16bit array-plätze nutze und beim schreiben auch eine 
bit-verschiebung stattfindet etc.

somit bedanke ich mich bei euch! :-)

[Peter D. (peda)]

Dein Programm ist mir viel zu kompliziert.
Wenn Du mehrere Variablen zusammenfassen willst, mach ne Struct daraus. 
Aber nicht sowas komisches zu Fuß.

Ne 32Bit Division im Interrupt wäre mir etwas grenzwertig.
Die Umrechnung der Ticks in was Du willst kann doch in aller Ruhe das 
Main machen. Das muß dann auch nicht tausende Register sichern und 
restoren für nen Funktionsaufruf.


Peter

[Adam P. (adamap)]

die 32bit division gehört dort nicht hin...ist nur testweise.
das mit den registern hat damit zu tun, dass sie später über uart 
zugänglich sein sollen. z.b. übers terminal mit "getreg xy".
bei variablen stelle ich mir das recht schwer vor.

[Peter D. (peda)]

Adam P. schrieb:
> bei variablen stelle ich mir das recht schwer vor.

Nö.
Du kannst die Elemente einer Struct auch Byte- oder Wortweise 
ansprechen, indem Du ne Union draus machst.


Peter

[Adam P. (adamap)]

eine union mit mehreren variablen? dann ist die doch nur so groß wie die 
größte variable die sie enthält.
kann mir das gerad nicht so ganz vorstellen wie du das meinst, hast du 
ein kleines code-bsp. vllt. ist es ja wirklich einfacher, dann werde ich 
mein ansatz mit den registern verwerfen :-D

[Karl H. (kbuchegg)]

Peter Dannegger schrieb:
> Adam P. schrieb:
>> bei variablen stelle ich mir das recht schwer vor.
>
> Nö.
> Du kannst die Elemente einer Struct auch Byte- oder Wortweise
> ansprechen, indem Du ne Union draus machst.

Und selbst wenn nicht, das Zauberwort heisst UART. Wenn du über UART auf 
die 'Register' zugreifst, hast du alle Zeit der Welt (ok, übertrieben), 
die Dinge auseinanderzupfriemeln - die UART Übertragung ist langsamer 
als das.

Du verlangsamst jetzt den häufigsten Fall nur um im Ausnahmefall 
schneller zu sein. So was nennt man Pessimierung und nicht Optimierung.

Was ist der absolut häufigste Fall?
Der, dass du einfach nur Ticks brauchst. Wenn du wissen willst, wieviel 
Zeiteinheiten das entspricht, dann kannst du das dort, wo du die Zeiten 
brauchst (normalerweise nur im Benutzerinterface) immer noch umrechnen. 
Und gibt dir der Benutzer eine Zeit vor, dann kannst du diese Zeit 
einfach in Ticks zurückrechnen und bist wieder auf der Ebene, in der du 
einfach nur mit Ticks hantierst.

[Adam P. (adamap)]

du hast recht keine frage, die berechnung sei mal vernachlässigt...
ist jetzt auch nicht die endlösung.

die ganze geschichte so wie sie im moment ist, habe ich nur zu 
testzwecken aufgebaut um die konfig des timers zu prüfen.

der häufigste fall ist sicherlich der, dass ich die ticks brauche -
da ich einen zeitlich definierten ablauf von funktionsaufrufen benötige.

[Peter D. (peda)]

Adam P. schrieb:
> eine union mit mehreren variablen? dann ist die doch nur so groß wie die
> größte variable die sie enthält.

Hier mal der Klassiker einer struct-union:

union b_w {
  struct{
    uint8_t l;
    uint8_t h;
  }b;
  uint16_t w;
};

Peter