Anfänger bittet um Hilfe zur Timerprogrammierung in C

[muetzi]

Aja, noch eins bitte.

@sprinter:

wegen der if-Bedingung:

Könnte man nicht gleich schreiben:

void ist_t0(void) interrupt 1
{

tsek++;

if(tsek==4000)
{
tsek=0;
P1=~P1;
}

}

Danke nochmal,

Gruß Jörn

Ich kapier einfach nicht, warum derjenig die Schleifen ineinander verschachtelt.

Jörn

[SprinterSB]

[...] sondern Aufgabe war, P1 mit einer Blinkfrequenz von 1Hz mit Hilfe von Timer0 zu realisieren.

In diesem Fall, muss P1 ne halbe Sekunke LOW sein, und ne halbe Sekunde HIGH. Das gibt ne Frequenz von 1Hz. Nach 1 Sekunde wiederholt sich dann alles. Wenn P1 1 Sek LOW ist etc, dann hast du ne Frequenz von 1/2 Hz. *haarespalt*

welchen Zweck erfüllt eigentlich die Endlosschleife while(1); im main().
Als ich Sie weggelassen hatte, funktionierte nichts mehr.
Meine Vermutung ist, dass die Timer-Initalisierungen damit unendlich oft ausgeführt werden können??? Aber ob das stimmt?

Zweck davon ist, daß man main() nicht verlässt. Wo würde man dann landen?

Das mit if (tsek==4000) stimmt auch.

Hallo Sprinter,

danke erst mal für deine Geduld!

Stimmt, das mit der Frequenz 1 Hz stimmt, weil in diesem Fall ja 1 Periode ne Sek. dauert!!!
Ja, ja , die lieben Grundlagen der Elektrotechnik/ Elektronik!

Mir rotieren schon mittlerweile die Leds mit ein paar MHz im Hirn!

wegen while(1); dann war meine Theorie richtig. Ohne while machts gleich einen RET und landet keine Ahnung wo.

Aber könnt ich dich trotzdem noch mit einer Frage quälen?!

Kannst du mir einen Grund nennen, warum der Programmierer eine verschachtelte if-Bedingung nimmt, man könnte die Zeitverzögerung ja auch anders programmieren.
Hat das vielleicht den Sinn, das nicht unnötig Prozessorzeit vernichtet wird, oder so???

Falls du mir dies noch beantworten könntest, DANKE!

Gruß, Jörn

PS. Dann wäre mein Problemchen vollständig gelöst!!

[muetzi]

Sorry, schon wieder nicht eingeloggt, das Forum haut mich immer nach einer gewissen Zeit raus.

Jörn

[SprinterSB]

Als mit vernichten von Prozessorzeit hat das nix zu tun. In einer ISR ist das eher ungünstig, und was die Codegröße angeht ist es auch schlechter als mit nur einem if.
Hat wohl didaktische Gründe. Erst mal auf eine ms und dann auf eine Sekunde. So kann man auch 1000s lang warten, ohne gruß was zu ändern. Mit nur 1 Variablen würd die überlaufen. Ich vermute mal, der Compiler arbeitet mit 16-bit-ints. Möglich wären auch 32 bit, ist aber eher unwahrscheinlich. Wie groß ein int werden kann siehst du in der Doku oder mit sizeof(int), das die die Anzahl der bytes gibt, die der Typ belegt.
Bit 16 bit ist
0x8000 = -32768 <= int <= 32767 = 0x7fff
, damit kann man nicht so weit zählen, und mit char schon gar nicht
0x80 = -128 <= char <= 127 = 0x7f

Als Zählvariablen nummt man übrigens besser unsigned, wegen

0 <= unsigned int <= 65535 = 0xffff
0 <= unsigned char <= 255 = 0xff

Wenn man mit einem Zähler eine Zeit von 10s warten wollte, würde man auf 40000 vergleichen. Ein guter Compiler meckert so was an, mit 'comparison always false/true due to limited range of data type' oder so. Mit unsigned short würd es noch passen.

[Bluehorn]

Als mit vernichten von Prozessorzeit hat das nix zu tun. In einer ISR ist das eher ungünstig, und was die Codegröße angeht ist es auch schlechter als mit nur einem if.

Hat wohl didaktische Gründe. Erst mal auf eine ms und dann auf eine Sekunde. So kann man auch 1000s lang warten, ohne gruß was zu ändern.

Ich schliesse mich der Vermutung an, dass es didaktische Gründe hat. Allerdings macht es auch durchaus Sinn, möglichst mit einer 8-Bit Variable (char) abzublocken, schliesslich handelt es sich hier um eine 8-Bit CPU.

Das halbiert dann in etwa die Zeit in der ISR gegenüber einem 16-Bit Zähler. Allerdings wird hier jedes 4.te Mal schon auf den 16-Bit Zähler "durchgeschaltet", insofern bringt diese Optimierung hier recht wenig.

Währe sinniger, eine 8-Bit Variable bis 250 laufen zu lassen und in der inneren Schleife dann bis 16 zu zählen. Dann würde man sogar ohne 16 Bit auskommen und die schnelle 8-Bit Operation wird zu 99,6% ausgeführt statt wie jetzt nur zu 75% der ISR-Aufrufe.