For-schleife im Interrupt

[M. S. (ekkie)]

Hallo,

ich würde gerne einen Binär-Zähler am Port D erstellen, welcher nur bis 
Sekunde 60 zählt. Dafür wollte ich mittels einer for-Schleife die 
Zählervariabel i begrenzen.

#define F_CPU 8000000

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

#define statusled (1<<PB1)

uint32_t timer_overflow_counter = 0;
uint8_t i,j;

void init_timer_0 (void)
{
  TCCR0A = 0x00;
  TCCR0B = (1<<CS01)+(1<<CS00);
  TIMSK0 = (1<<TOIE0);
  TCNT0 = 131;
}
int main(void)
{
  DDRD = 0xff;        //Pin D alle auf Ausgang
  DDRB = 0xff;        //Pin B alle auf Ausgang
  PORTD |= 0xff;        //alle Pull-up Widerstände aktivieren
  PORTB |= 0xff;        //alle Pull-up Widerstände aktivieren
  DDRC &= ~(1<<PC2);      //Pin C2 als Eingang

  init_timer_0();
  sei();


    while (1) 
    {
  asm("NOP");
  }
}

  ISR(TIMER0_OVF_vect)
  {
    
    TCNT0=131;

    if(timer_overflow_counter <=999)
    timer_overflow_counter++;
  
    else
    {
    PORTD=i;
    i++;
    timer_overflow_counter=0;
    }
  }

in diesem Fall habe ich es schon geschafft es hochzählen zu lassen, er 
zählt aber bis zum Überlaufen.

Es ist nicht so als hätte ich nicht schon einige Positionen für die 
for-Schleife ausprobiert, allerdings klappt jedes mal nicht.

Kann mir jemand helfen wie ich so etwas konfiguriere bzw. wo ich die 
for-Schleife einfügen muss?

Vielen Dank

[Carl D. (jcw2)]

Wieso kann man den Millisekunden-Zähler auf max 999 begrenzen, ahnt aber 
nicht wie man den Seckunden-Zähler auf max 60 (oder vielleicht 59) 
begrenzt?

[Axel S. (a-za-z0-9)]

Carl D. schrieb:
> Wieso kann man den Millisekunden-Zähler auf max 999 begrenzen, ahnt aber
> nicht wie man den Seckunden-Zähler auf max 60 (oder vielleicht 59)
> begrenzt?

Weil man das eine irgendwo abgeschrieben hat?

[Kirsch (Gast)]

Meik S. schrieb:
> uint32_t timer_overflow_counter = 0;

entweder du deklarierst die Variable in der ISR mit static
oder global mit volatile

[Carl D. (jcw2)]

Axel S. schrieb:
> Carl D. schrieb:
>> Wieso kann man den Millisekunden-Zähler auf max 999 begrenzen, ahnt aber
>> nicht wie man den Seckunden-Zähler auf max 60 (oder vielleicht 59)
>> begrenzt?
>
> Weil man das eine irgendwo abgeschrieben hat?

Mach auch immer öfter, da ja irgendwann die Zeit zum selbermachen 
knapper wird. Muß ja aber nicht dazu führen, daß man das abgeschriebene 
nicht versteht.
Eigentlich wollte ich den TO nur in die richtige Richtung schubsen. 
Hilft manchmal.

Und wie ich gerade sehe: nicht wärend des Schreibens in einer anderen 
Sprache denken. Das führt zu Se[ck]unden. ;-)

[M. S. (ekkie)]

ich habe nie gesagt, dass ich es nicht abgeschrieben hätte. Trotzdem 
wäre eine Erklärung sehr hilfreich, da ich ja anscheinend das Thema 
nicht wirklich durchdrungen habe.
Wie ist den mit dem 8-bit Timer umzugehen in so einem Fall?
Brauche ich nun keine For-Schleife mehr?

[M. S. (ekkie)]

ich danke für bisherigen die Tipps!

[Carl D. (jcw2)]

Falls du wirklich verstehen willst, dann ist das zu begrüssen!

Noch ein Tipp:
Zur genauen Sekunde taugt der Code nicht, da er nicht CTC-Mode nutzt 
sondern selber den "Reload"-Wert in den Timer schreibt. Damit ist zur 
Quarzungenauigkeit noch der Faktor ISR-Latenz im Spiel.

Besser CTC-Mode und CompA-Isr. Da läuft der Timer "Taktgenau" von 0 bis 
zum Inhalt des CompareA-Registers und setzt (in HW) dann auf 0 zurück. 
So ist eventuell die CompA-ISR mal verzögert, aber diese Verzögerungen 
addieren sich nicht zum "Gesammtnachgehen". Wenn z.B. Irgewann mal 
andere Interrupts ins Spiel kommen und die "Uhr" auf diese warten muß.

[c-hater (Gast)]

Carl D. schrieb:

> Axel S. schrieb:

>> Weil man das eine irgendwo abgeschrieben hat?

> Mach auch immer öfter, da ja irgendwann die Zeit zum selbermachen
> knapper wird. Muß ja aber nicht dazu führen, daß man das abgeschriebene
> nicht versteht.

Das sollte man aber IMMER. Zumindest das Konzept der fremder Software, 
die man nutzt, sollte man immer verstehen, natürlich nicht 
notwendigerweise auch jedes Detail, denn dann könnte man sie ja auch 
gleich selber schreiben. Was allerdings, zumindest gelegentlich, 
tatsächlich die bessere Lösung ist...

Wer sich aber nicht einmal bemüht, das Konzept (und damit die dahinter 
liegenden Protokolle bzw. Hardwaremodule) zu verstehen, der wird 
spätestens mittelfristig immer scheitern.

Also Mitglied der Horde armer Idioten sein, die sich heutzutage 
"Programmierer" nennen und nichtmal rot werden dabei. Die kennen's 
einfach nicht mehr anders. Diese Flachwichser glauben doch tatsächlich, 
mit "kompiliert ohne Fehler" wäre ihr Job getan. Was dabei tatsächlich 
rauskommt, darf man sich in einer unendlich Anzahl von grausam 
schlechten Inkarnation von Firmwares selbst recht teuerer Geräte 
ansehen. Da rollen sich einem teilweise die Fußnägel hoch ob der 
grenzenlosen Idiotie der Benutzer der "raubkopierten" (AKA: ohne Sinn 
und Verstand benutzten) Libs...

[Carl D. (jcw2)]

c-hater schrieb:
> Carl D. schrieb:
>
>> Axel S. schrieb:
>
>>> Weil man das eine irgendwo abgeschrieben hat?
>
>> Mach auch immer öfter, da ja irgendwann die Zeit zum selbermachen
>> knapper wird. Muß ja aber nicht dazu führen, daß man das abgeschriebene
>> nicht versteht.
>
> Das sollte man aber IMMER. Zumindest das Konzept der fremder Software,
> die man nutzt, sollte man immer verstehen, natürlich nicht
> notwendigerweise auch jedes Detail, denn dann könnte man sie ja auch
> gleich selber schreiben. Was allerdings, zumindest gelegentlich,
> tatsächlich die bessere Lösung ist...
Mal wieder ein Kommentar ohne den Inhalt erfaßt zu haben ;-(

> Wer sich aber nicht einmal bemüht, das Konzept (und damit die dahinter
> liegenden Protokolle bzw. Hardwaremodule) zu verstehen, der wird
> spätestens mittelfristig immer scheitern.
Vor 35Jahren hab ich alles selbst schreiben müssen, heute, auch wegen 
wenig verbleibender Lebenszeit und besserem zu tun, lasse ich mich gerne 
von fremdem, freien Code inspirieren. Die meisten um mich rum wüssten 
gar nicht, wo sie die Lösungen für ihren Probleme finden könnten und wie 
sie diese von Sprache A nach B übertragen sollten.

> Also Mitglied der Horde armer Idioten sein, die sich heutzutage
> "Programmierer" nennen und nichtmal rot werden dabei. Die kennen's
> einfach nicht mehr anders. Diese Flachwichser glauben doch tatsächlich,
> mit "kompiliert ohne Fehler" wäre ihr Job getan. Was dabei tatsächlich
> rauskommt, darf man sich in einer unendlich Anzahl von grausam
> schlechten Inkarnation von Firmwares selbst recht teuerer Geräte
> ansehen. Da rollen sich einem teilweise die Fußnägel hoch ob der
> grenzenlosen Idiotie der Benutzer der "raubkopierten" (AKA: ohne Sinn
> und Verstand benutzten) Libs...

Zum Glück haben manche jedes Stück Software zwischen ihnen und dem Forum 
verstanden und sicher längst in Assembler nachgebaut.
Wie nennen diese sich noch mal selbst?  "grenzenlose Idioten", oder so!

[M. S. (ekkie)]

Vielen Dank Carl D.,

die Tipps haben mir sehr geholfen. Auch der Rad auf den CTC-Modus ist 
sehr wichtig für mich gewesen.

zum einen habe ich mein Problem erkannt in dem bisherigen Code. Warum 
sollte ich eine for-schleife benutzen wenn ich der if-else Bedingungen 
mit einer fixen Zeit eine Begrenzung der Aufzählung (z.B. noch eine 
umschließende if-else Bedingung mit 60 Sekunden) erteilen kann.

Zum anderen möchte ich nochmals allgemein in diesem Forum 
daraufhinweisen, dass ich hier eine Problemstellung aufführe an der ich 
selbst nicht weitere Antworten finde. Das hat auch nichts damit zu tun, 
dass ich den oben schon aufgeführten Code nicht verstehe, sondern eher 
weitere fordernde Funktionen an den Code nicht anwenden kann, da ich 
nicht jede Funktion in ihrer Vollständigkeit verstehe.

[c-hater (Gast)]

Carl D. schrieb:

> Zum Glück haben manche jedes Stück Software zwischen ihnen und dem
> Forum verstanden

Nicht jedes. Aber definitiv jedes von mir benutzte Stück fremden Codes 
habe ich zumindest verstanden, sehr vieles davon habe ich allerdings 
auch nur als Anregung, Leitfaden und eine Art Nachschlagewerk für eine 
eigene Implementierungen benutzt.

> und sicher längst in Assembler nachgebaut.

Das allerdings nur dort, wo es wirklich nötig war oder zumindest 
wünschenswert wegen der zusätzlichen Freiheitsgrade und 
Performance-Reserven eines komplett in Assembler ausgeführten 
Gesamtwerkes. Sprich: je kleiner und weniger leistungsfähig die 
Hardware, desto wahrscheinlicher genoß der Code eine kompetente 
Umsetzung in Assembler...

Das ist allerdings wenig überraschend: Auch die C-Only-Typen werfen, 
wenn's eng wird, gerne die so hochgelobte "Portabilität" ihrer 
fetischistisch geliebten Nerd-Sprache gerne weg, um den zeitkritischen 
Teil in Assembler zu erledigen. Am Ende bleibt also ein Nicht-Portables 
Programm (also kein Unterschied zu einer reinen Asm-Implementierung), 
bloß mit suboptimalen Laufzeiteigenschaften, weil ihnen durch die nötige 
Rücksicht auf den vollblöden Compiler halt doch nicht alle möglichen 
Optimierungen offen stehen...

Ich mache es eben so, dass ich die "Nicht-Portabilität" als 
Voraussetzung für die Funktion auf der Zielarchitektur akzeptiere und 
alles andere als nachgeordnet wichtig betrachte. Was für mich natürlich 
relativ einfach ist, da ich schon immer alles auch in Assembler 
programmiere und für viele Architekturen über umfangreiche Sammlungen 
von effizient umgesetzten Standardroutinen verfüge. Also genau das, was 
dir auch dein heißgeliebter Compiler nur liefert, nur kontrolliere ich 
das selber vollständig und kann es deshalb in den Rahmen der 
zeitkritischen Sachen recht problemlos mit minimalem oder sogar komplett 
ohne Performance-Loss einpassen. Genau das geht aber nicht, solange du 
die Compiler-Konventionen gebunden bist...

Capisce stupido?

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

c-hater schrieb:
> Capisce stupido?

Und wieder mal endloses Geseier ohne einen einzigen hilfreichen Hinweis. 
Halt dich doch einfach raus, wenn es um C geht, denn du haßt es ja 
sowieso.

Der richtige Hinweis kam aber schon ganz oben:

Kirsch schrieb:
> entweder du deklarierst die Variable in der ISR mit static
> oder global mit volatile
Wenn 'timer_overflow_counter' nirgends sonst benutzt wird, tendiere ich 
zum static in der ISR, finde ich übersichtlicher. Das gleiche gilt für 
i.

[A. S. (Gast)]

c-hater schrieb:
> Am Ende bleibt also ein Nicht-Portables Programm (also kein Unterschied
> zu einer reinen Asm-Implementierung),

Jetzt ernsthaft? Du hasst C und programmierst Assembler? Und siehst 
keinen Unterschied darin, beim Plattformwechsel 0,1% in C zu 
überarbeiten, vs. Alles neu?

[c-hater (Gast)]

Matthias S. schrieb:
> c-hater schrieb:
>> Capisce stupido?
>
> Und wieder mal endloses Geseier ohne einen einzigen hilfreichen Hinweis.

Der hifreiche Hinweis ist: C ist weitehend nutzlos, zumindest für kleine 
Architekturen und Echtzeit-Anwendungen. In der Konsequenz: lerne die 
Assembler-Sprache des Zielsystems und seine Architektur. Das ist auf 
lange Sicht hilfreicher als jede fortgeschrittene Kenntnis von 
C/C++/whatevever, wobei man die de facto natürlich auch benötigt, um 
vorhandenen Code verstehen zu können...

Fakt ist: man muss ALLES können, um einerseits das Zielsystem optimal 
nutzen zu können und andererseits Vorteile aus der Existenz öffentlich 
verfügbaren Codes ziehen zu können. Wenn man's nicht kann, muss man's 
lernen.

That's it. Ich begreife nicht, warum es manchen Leuten so schwer fällt, 
diesen einfachen Sachverhalt zu verstehen.

[c-hater (Gast)]

Achim S. schrieb:

> Jetzt ernsthaft?

Jepp.

> Du hasst C und programmierst Assembler?

Nicht ganz. Ich programmiere natürlich auch in C. Ich weigere mich nur, 
das als Fetish und unabänderliches Axiom aufzufassen...

> Und siehst
> keinen Unterschied darin, beim Plattformwechsel 0,1% in C zu
> überarbeiten, vs. Alles neu?

Tatsache ist, dass bei einem Wechsel der Hardwareplattform typisch 
wesentlich mehr als 0,1% des Codes anzufassen ist. Genau das ist der 
Effekt der Nutzung von C mit Assembler-Einschüben. Es ist dann eben 
nicht mehr "portabel". Wird aber, eben wegen der Unvollkommenheit der 
C-Compiler, weithin genutzt.

Und wenn man kein Flachwichser ist, weiß man, dass vieles in der 
scheinbaren Leichtigkeit von C auch einfach nur Zielsystem-abhängiger 
Assemblercode ist. Schönes Beispiel: die Unterstützung für 
Gleitkommatypen und -operationen. Da fällt den C-Only-Wichsern oft genug 
schon innerhalb einer Zielarchitektur die Scheiße auf die Füsse. Weil 
sie entweder zu blöd sind, die richtigen Libs einzubinden oder sogar 
schon zu bescheuert, um zu wissen, ob ihre Zielarchitektur überhaupt 
Float in Hardware unterstützt...

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

c-hater schrieb:
> Nicht ganz. Ich programmiere natürlich auch in C. Ich weigere mich nur,
> das als Fetish und unabänderliches Axiom aufzufassen...

Das interessiert hier keinen Menschen, da es auch niemand ausser dir 
macht.

Da der TE nun mal in C programmiert hat, ist es völlig sinnlos, mal 
wieder eine deiner üblichen Tiraden abzuseilen. Es ist C, bleibt C und 
der TE wirds sicher nicht in Assembler nochmal schreiben.

[Carl D. (jcw2)]

c-hater schrieb:
> Matthias S. schrieb:
>> c-hater schrieb:
>>> Capisce stupido?
>>
>> Und wieder mal endloses Geseier ohne einen einzigen hilfreichen Hinweis.
Bist mal wieder im Bad am posten?

> Der hifreiche Hinweis ist: C ist weitehend nutzlos, zumindest für kleine
> Architekturen und Echtzeit-Anwendungen. In der Konsequenz: lerne die
> Assembler-Sprache des Zielsystems und seine Architektur. Das ist auf
> lange Sicht hilfreicher als jede fortgeschrittene Kenntnis von
> C/C++/whatevever, wobei man die de facto natürlich auch benötigt, um
> vorhandenen Code verstehen zu können...
Es gibt viele weitgehend nutzlose Dinge, manche sind hier in dem 
Thread/Forum mit einem ganz speziellen Tag markiert.
C gehört aber nicht dazu.

> Fakt ist: man muss ALLES können, um einerseits das Zielsystem optimal
> nutzen zu können und andererseits Vorteile aus der Existenz öffentlich
> verfügbaren Codes ziehen zu können. Wenn man's nicht kann, muss man's
> lernen.
Nein, dann würden wir allen noch nicht mal auf Bäumen sitzen. Unser Art 
wurde durch Arbeits- und Wissensteilung zu dem was sie heute ist.

> That's it. Ich begreife nicht, warum es manchen Leuten so schwer fällt,
> diesen einfachen Sachverhalt zu verstehen.
Vielleicht weil er (für fast alle) nicht richtig ist?

[Thomas E. (thomase)]

c-hater schrieb:
> Und wenn man kein Flachwichser ist

c-hater schrieb:
> den C-Only-Wichsern

c-hater schrieb:
> zu blöd sind

c-hater schrieb:
> sogar schon zu bescheuert

Hast du eigentlich niemanden, dem du bei einem deiner Tourette-Anfälle 
direkt anpöbeln kannst?

[Carl D. (jcw2)]

Thomas E. schrieb:
> c-hater schrieb:
>> Und wenn man kein Flachwichser ist
>
> c-hater schrieb:
>> den C-Only-Wichsern
>
> c-hater schrieb:
>> zu blöd sind
>
> c-hater schrieb:
>> sogar schon zu bescheuert
>
> Hast du eigentlich niemanden, dem du bei einem deiner Tourette-Anfälle
> direkt anpöbeln kannst?

Seine Version wirkt nur über Forensoftware.

[Thomas E. (thomase)]

Carl D. schrieb:
> Seine Version wirkt nur über Forensoftware.

Aah, Tourette 2.0, die Online-Version.

[Carl D. (jcw2)]

Thomas E. schrieb:
> Carl D. schrieb:
>> Seine Version wirkt nur über Forensoftware.
>
> Aah, Tourette 2.0, die Online-Version.
Online/2.0 war (vor)gestern.

Tourette-Cloud würde man das heute nennen müssen.