RN-Control Quarz-Merkwürdigkeit ... !?

Hallo an alle,

ich versuche derzeit, mein RN-Control 1.4 zu programmieren. Das funktioniert soweit ganz gut und meine ersten Gehversuche klappen auch - bis auf eine Merkwürdigkeit:

Ich nutze das AVR-Studio zusammen mit dem AVR-GCC. Da stellt man also über die Projekt-Optionen den Controller ein und evtl. die Quarz-Frequenz (optional).

Jetzt habe ich folgende, reproduzierbare Ergebnisse:
- Wenn ich in den Projekt-Optionen 1 MHz einstelle, dann läuft alles (vor allem der Sound) so, wie gewünscht.
- Wenn ich aber 16 MHz einstelle, soviel, wie der genutzte Quarz auch hat, dann klingt alles sehr "dämlich" (offensichtlich wird nicht mit 16 MHz gerechnet).

Erste Annahme: Fuse-Bits für die interne Clock oder 8-Prescaler.
Also hab ich mir die Fusebits vorgenommen. Die sehen aber alle sehr gut aus und vor allem:
- Wenn ich den Quarz entferne, bleibt das Programm stehen!
(Das ist doch ein Beweis dafür, dass er den externen Quarz nutzt ... ?!)
- Setze ich andere Quarze ein (langsamere), dann geht alles -wie erwartet- langsamer.

Also: Warum muss ich 1MHz einstellen, damit die 16MHz funktionieren?
Soweit ich das gesehen habe, hat der M32 keinen 8-Prescaler... ?!

Danke für eure Mühen!

Hi,

die in den Projektoptionen eingestellte Frequenz sollte auf die Hardware direkt keinen Einfluss haben, allerdings auf die Software: Überall, wo Du z.B. "_delay_ms(..)/_delay_us(..)" einsetzt oder wo sonst auf F_CPU zugegriffen wird, wird die in den "Project Options" eingetragene Frequenz genutzt. Könnte es es sein, dass das bei Dir die Ursache für das beschriebene Verhalten ist?

Ja, beim ATmega32 gibt es kein CKDIV8.

Gruß

Fred

Genau das ist sie. Aber sie weicht merkwürdig von der (von mir erdachten) Realität ab.

Lasse ich diesen optionalen Parameter in den Projektoptionen weg, so warnt die delay.h, dass kein F_CPU gesetzt wurde, und setzt es selbst auf 1.000.000 (was ja komischerweise funktioniert).

D.h. ist die CPU-Frequenz (softwareseitig) auf 1 MHz eingestellt, geht mit dem 16 MHz-Quarz alles korrekt, ist sie jedoch auf 16 MHz eingestellt, geht das Programm mega-langsam (ich schätze mal 1/16-fach).

Hast Du denn nochmal nachgerechnet, ob die von Dir gewünschtern Verzögerungen (_delay_xx(..)) in Deiner Software auch tatsächlich richtig ausgeschrieben sind?
Wenn wir davon ausgehen, dass der Prozessor tatsächlich mit 16MHz läuft, was er laut ja wohl tut, wie Du anhand der Fuses und der Quarz-Experimente gezeigt hast, sehe ich da eher ein Software-Problem.
Hast Du mal im vom AVR Studio generierten Makefile nachgesehen, ob dort tatsächlich etwas wie "-DF_CPU=16000000UL" steht?

Ja, ich habe nachgesehen, es steht jeweils der korrekte Wert für F_CPU drin.

Es ist übrigens ein Teil des Beispielcodes aus dem RN-Wissens-Bereich. Die Soundausgaben selber zeigen bereits, ob es die richtige Frequenz ist. Und bei 1 MHz kommt eine kleine Melodie (so wie im Beispielprogramm vorgesehen) und bei 16 MHz kommt nur ewig langes, nerviges Gebrumme (zu niedrige Frequenz, da zu hoch eingestellte Taktrate).
Die Funktion "Sound" aus dem Beispiel nutzt ja die _delay_ms() aus der delay.h, die wiederum mit 1 MHz perfekt läuft, obwohl der Quarz 16 MHz hat.

Komisch... Meinst Du diese Software? Hast Du schon probiert, wie es mit dem Simulator klappt (nur eine delay-Routine, z.B.)?

Was soll wohl dieser Satz im Kommentar der "sound(..)"-Funktion?
Zitat: "Der Multiplikator von 15 in der Länge gleicht die seltsame Dauer, die die Delay-Schleife hat, aus (die kommt aus irgend einem Grund nicht mal annähernd an Millisekunden heran)."

Evtl. mit alter WINAVR-Version entwickelt??

Ja, genau diese Software meine ich. Wobei ich nur die waitms-, die sound- und die lauflicht-Funktionen übernommen habe. Das ganze wurde dann per Copy and Paste in ein neues Projekt im AVRStudio eingefügt.

Also keine Ideen, ja?

Doch, die Sache mit dem komischen Korrekturfaktor (s.o.) in der "sound()"-Funktion!

Achso. ok.

Es gibt eine neue Erkenntnis, die Deine Theorie stützt:
Ich habe jetzt aus dem RN-Wissen die Interrupt-Warteroutine hinzugefügt. (Da wird ein Timer gestartet, und der Interrupt sagt einem dann, wann es weitergeht)
Diese habe ich umgebaut, so dass sie das Lauflicht kontrolliert, und nicht die waitms-Funktion. D.h. Das Lauflicht wird jetzt ausschließlich über den internen Timer gesteuert.

Und siehe da: Ich musste die Wartezeiten der LEDs auf um das 16-fache erhöhen, damit das Lauflicht wieder die gleiche Geschwindigkeit hat, wie vorher.

Ich danke Dir vielmals, Fred.

Fazit: Die waitms-Funktion und der Sound-Korrekturfaktor sind die Stolperfallen gewesen, die mich glauben ließen, dass alles mit 1MHz laufe.

Freut mich, dass es jetzt klappt! Ich nehme einfach an, der Autor hat die "sound(..)"-Funktion unter einer alten avr-gcc Version entwickelt, bei der die Begrenzung von 262ms/F_CPU ( http://www.nongnu.org/avr-libc/user-...il__delay.html ) noch absolut war.