[[AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR#Kalibrieren_des_internen_Oszillators_mit_Timer2_als_Zeitbasis|Kalibrieren des internen Oszillators mit Timer2 als Zeitbasis]]
Jörg Wunsch schrieb:> Irgendwas ist in dem Artikel jetzt aber drin, was ihn mächtig breit> macht. Auf einem kleinen Bildschirm ist er damit praktisch unlesbar> geworden.
danke für den Hinweis.
Das war ein Kommentar im Programmbeispiel. Der wird nicht umgebrochen.
Habe ihn jetzt oben drüber gesetzt. Hab ich natürlich auf meinem
24-Zöller nicht bemerkt. Jetzt geht es auch auf nem 5:4 19".
mfg.
Danke. Ich habe noch ein paar weitere Zeilen umgebrochen und
nachgesetzte Kommentare in die Zeile darüber verlagert. Jetzt
skaliert es ordentlich bis 800px Fenstergröße herunter. Ich
hoffe, damit ist es selbst auf "mobilen Endgeräten" noch
einigermaßen benutzbar.
Dabei habe ich noch einen Logikfehler beseitigt (in der Routine
fürs Kalibrieren des RC-Oszillators): das logische UND ist "&&",
nicht "&". Da hilft es auch nichts, wenn man um die Vergleiche
herum redundante Klammern schreibt … Ich denke außerdem, dass
man den Zählerwert aus TCNT1 als Snapshot in einer temporären
Variablen festhalten sollte, statt ihn jedesmal aus dem IO-Register
zu lesen. Erstens ist das schneller, und zweitens könnte TCNT1
ja durchaus während der diversen Vergleiche bereits um eins
weiterzählen.
Schließlich und endlich: Bezeichner mit einem führenden Unterstrich,
gefolgt von einem Großbuchstaben (_COUNT_PRE und Konsorten) haben in
Applikationscode nichts zu suchen; derartige Bezeichner reserviert
der C-Standard "für die Implementierung", also für Compiler und
Standardbibliothek.
Jörg Wunsch schrieb:> Danke. Ich habe noch ein paar weitere Zeilen umgebrochen und> nachgesetzte Kommentare in die Zeile darüber verlagert. Jetzt> skaliert es ordentlich bis 800px Fenstergröße herunter. Ich> hoffe, damit ist es selbst auf "mobilen Endgeräten" noch> einigermaßen benutzbar.
Werde ich mir für die Zukunft merken. Hab ich überhaupt nicht drüber
nachgedacht.
> Dabei habe ich noch einen Logikfehler beseitigt (in der Routine> fürs Kalibrieren des RC-Oszillators): das logische UND ist "&&",> nicht "&". Da hilft es auch nichts, wenn man um die Vergleiche
Aber die Ergebnisse der beiden Vergleiche sind 0 oder 1. OK, 0 oder !0.
!0 ist aber 1. Aber da habe ich wohl keinen Anspruch drauf. Würde "&&"
aber in der Funktion einen Unterschied machen, dürfte es mit "&" nicht
funktionieren. Tut es aber. Aber ich lasse das "&&" drin.
> herum redundante Klammern schreibt … Ich denke außerdem, dass> man den Zählerwert aus TCNT1 als Snapshot in einer temporären> Variablen festhalten sollte, statt ihn jedesmal aus dem IO-Register> zu lesen. Erstens ist das schneller, und zweitens könnte TCNT1> ja durchaus während der diversen Vergleiche bereits um eins> weiterzählen.
Der Timer zählt nicht weiter, weil er angehalten wird.
1
GTCCR=(1<<TSM)|(1<<PSRSYNC);//Stop Timer1
Aber ich hab die Variable trotzdem eingebaut. Spart auch ein bisschen
Code.
> Schließlich und endlich: Bezeichner mit einem führenden Unterstrich,> gefolgt von einem Großbuchstaben (_COUNT_PRE und Konsorten) haben in> Applikationscode nichts zu suchen; derartige Bezeichner reserviert> der C-Standard "für die Implementierung", also für Compiler und> Standardbibliothek.
Die Underscores wollte ich gerade wegnehmen. Aber das hast du ja schon
gemacht. Danke. Die sind da reingekommen, weil ich die Bezeichner ein
bisschen deutlicher von den Registernamen abheben wollte. Ursprünglich
waren da gar keine Underscores drin. Das war wohl etwas zu viel des
Guten. Typischer Fall von Verschlimmbesserung durch die gedankenlose
Verwendung von "Replace".
mfg.
Thomas Eckmann schrieb:> Aber die Ergebnisse der beiden Vergleiche sind 0 oder 1. OK, 0 oder !0.> !0 ist aber 1. Aber da habe ich wohl keinen Anspruch drauf. Würde "&&"> aber in der Funktion einen Unterschied machen, dürfte es mit "&" nicht> funktionieren. Tut es aber.
Ja, es funktioniert schon. Aber es ist logisch nicht korrekt, und
kann zu gedankenloser Benutzung des bitweisen UND-Operators führen
an Stellen, wo der logische UND-Operator wirklich wichtig ist.
Wie du das in deinem Code machst und ob du jedesmal drüber nachdenkst,
ob zwischen beiden hier ein Unterschied besteht, ist was anderes :),
aber in einem öffentlichen Tutorial sollte man es „politisch korrekt“
schreiben.
> Der Timer zählt nicht weiter, weil er angehalten wird.
Gut, soweit war ich durch die Logik nicht durchgestiegen, daher
hatte ich das auch nur hier als Diskussion in die Runde geworfen.
> Die Underscores wollte ich gerade wegnehmen. Aber das hast du ja schon> gemacht. Danke. Die sind da reingekommen, weil ich die Bezeichner ein> bisschen deutlicher von den Registernamen abheben wollte.
Verstehe ich. In dem Falle sind sie aber alle lang genug, dass sie
nicht mit Registern kollidieren. Ansonsten kann man auch sowas machen
wie ein “C_” voransetzen (für „Konstante“), also “C_COUNT_PRE” etc.
Ne ist klar. Das mit der Politcal Correctness. Braucht man gar nicht
drüber diskutieren.
Ich benutze das "&&" so gut wie gar nicht. Sondern setze da eher ein
"!!" vor, um !0 auf 1 zu zwingen. Aber in einem Tutorial haben solche
Tricks, zumindest an dieser Stelle, nichts verloren.
Ich hab den Beitrag jetzt mal ganz rausgenommen. Durch den Einbau der
Variablen sind jetzt ein paar Unsinnigkeiten entstanden. Ich muss das
nochmal überarbeiten. Hab da jetzt aber keine Zeit zu. Werde das aber
heute abend wieder reinstellen.
mfg.
Der Beitrag ist wieder online.
Ich habe jetzt die Bezeichner etwas schlanker gemacht und nur noch in
der Mitte mit einem Underscore tailliert.
Die Notwendigkeit des Prescaler-Reset durch Starten und Stoppen des
Timer1 habe ich erlärt. Das wirkt sonst nämlich auf den ersten Blick
nach dem Einfügen der TCNT-Snapshot-Variable überflüssig.
mfg.
Thomas Eckmann schrieb:> Ich benutze das "&&" so gut wie gar nicht. Sondern setze da eher ein> "!!" vor, um !0 auf 1 zu zwingen.
Damit verschenkst Du Optimierungspotential.
Mit dem && kann der Compiler den 2.Ausdruck überspringen, das Programm
wird also deutlich schneller ausgeführt.
Ein & zwingt ihn, immer alle Ausdrücke auszuführen, auch wenn das
Ergebnis schon früher feststeht.
Peter Dannegger schrieb:> Thomas Eckmann schrieb:>> Ich benutze das "&&" so gut wie gar nicht. Sondern setze da eher ein>> "!!" vor, um !0 auf 1 zu zwingen.>> Damit verschenkst Du Optimierungspotential.>> Mit dem && kann der Compiler den 2.Ausdruck überspringen, das Programm> wird also deutlich schneller ausgeführt.>> Ein & zwingt ihn, immer alle Ausdrücke auszuführen, auch wenn das> Ergebnis schon früher feststeht.
Ja, das ist richtig. Vielleicht sollte ich mir das mal angewöhnen.
mfg.