Hallo, ich habe mir soeben die neueste Version des Atmel Studio 7 installiert, welche hier zu finden ist. Jedoch suche ich die Option die CPU-Frequenz durch 8 zu teilen (CKDIV8), was sonst bei den Fuses einzustellen war. Wo ist das hin? ... oder gab es das beim Mega8 gar nicht?... ich bin verwirrt.
>oder gab es das beim Mega8 gar nicht?.
Die Fuse hat er nicht. Das geht über die CKSEL Fuses.
Ich kenne jetzt die Version 7 nicht, würde aber nach den verwendeten Abkürzungen CKOPT und SUT_CKSEL gehen und das mal mit dem Handbuch der Software und dem Datenblatt vergleichen. "CK" hat bei Atmel oft irgendwie mit dem Takt zu tun. Ausserdem ergibt sich aus der Beschreibung der Auswahl bei SUT_CKSEL die Möglichkeit, dass das CKDIV8 da mit einbezogen ist und von der GUI dann auscodiert wird.
holger schrieb: >>oder gab es das beim Mega8 gar nicht?. > > Die Fuse hat er nicht. Das geht über die CKSEL Fuses. Das erklärt einiges...
Frank L. schrieb: > im Datenblatt nachsehen wäre unter deiner Würde? Willst du jetzt einen Preis für die Antwort?
Günter schrieb: > Frank L. schrieb: >> im Datenblatt nachsehen wäre unter deiner Würde? > > Willst du jetzt einen Preis für die Antwort? Klar will er den. Der Preis den Du für das Nicht-Nachsehen in Handbuch und Datenblatt bekommen hast, ist ein Wanderpokal.
ich habe deshalb gefragt, da ich scheinbar Timing-Probeleme habe. Woran kann es dann noch liegen, wenn ein delay_ms(200) ca. 2sek. lang braucht? CKDIV8 gibt es nicht, und da der Takt auf 1Mhz int. Osz. eingestellt ist, gehe ich davon aus, dass das passt.
1 | #define F_CPU 1000000UL |
2 | #include <util/delay.h> |
3 | #include <avr/io.h> |
4 | |
5 | |
6 | int main (void) |
7 | {
|
8 | |
9 | DDRB=0x01; |
10 | |
11 | while (1) |
12 | {
|
13 | PORTB|=(1<<PB0); |
14 | _delay_ms(200); |
15 | PORTB&=~(1<<PB0) |
16 | _delay_ms(200); |
17 | } |
18 | |
19 | |
20 | } |
>Woran kann es dann noch liegen, wenn ein delay_ms(200) ca. 2sek. lang >braucht? Optimierung beim Compiler eingeschaltet?
holger schrieb: >>Woran kann es dann noch liegen, wenn ein delay_ms(200) ca. 2sek. > lang >>braucht? > > Optimierung beim Compiler eingeschaltet? Steht auf Optimize(-01)
Hm. Hast Du ein Oszilloskop? Falls nicht: Auf welche Weise hast Du die tatsächliche Blinkfrequenz festgestellt? Es geht nur darum wie genau die Angabe wohl vermutlich ist. Faktor 10 ist eher ungewöhnlich. Zu erwarten wäre eher irgendeine 2-er Potenz. Falls doch: Nimm doch einfach mal die delays raus und miss mit dem Oszilloskop den Takt nach. Das müsste irgendwas im 100 Kilohertz-Bereich ergeben. Vergleiche das mit dem aus dem Assemblercode ableitbaren Takt. Falls das wie erwartet ausfällt, liegts am delay. Falls nicht, wird es auch schwierig, dann nämlich liegt es vermutlich an der Handhabung (Compilierung, Flashen) und die meisten Leute sind bis zum Beweis des Gegenteils davon überzeugt, dass sie alles richtig machen. (Diesen Fehler mache ich auch hin und wieder). Es gab nämlich lange Zeit viel hin und her wegen der delay-Implementierungen und Anwendung. Ob das tatsächlich noch relevant ist, weiß ich nicht, weil ich die Version 7 nicht verwende und nicht weiß welche Compiler und Lib-Versionen dazu geliefert werden. Aber um das zumindest mal grob einschätzen zu können, wäre es gut Compiler-Version und die Version der avr-lib zu kennen.
>#define F_CPU 1000000UL
Das gehört in das Makefile bzw. die Settings im Studio und NIE in ein .c
oder .h File.
Pete K. schrieb: >>#define F_CPU 1000000UL > > Das gehört in das Makefile bzw. die Settings im Studio und NIE in ein .c > oder .h File. Wärst Du so nett und gibst eine Begründung dafür? Funktioniert es andernfalls garnicht oder ist das eine Stilfrage oder geht es um etwas anderes?
TeilerUndHerrscher schrieb: > Hm. Hast Du ein Oszilloskop? > > Falls nicht: Auf welche Weise hast Du die tatsächliche Blinkfrequenz > festgestellt? Es geht nur darum wie genau die Angabe wohl vermutlich > ist. > Faktor 10 ist eher ungewöhnlich. Zu erwarten wäre eher irgendeine 2-er > Potenz. Nur pi*Daumen. Ich werde mich morgen mal ein Oszilloskop besorgen bei einem Kollegen. welche Compiler und Lib-Versionen dazu geliefert werden. > Aber um das zumindest mal grob einschätzen zu können, wäre es gut > Compiler-Version und die Version der avr-lib zu kennen. Kannst du mir eben sagen, wo man das nachsehen kann in Atmel Studio?
Au shit. Ich habe ganz furchtbar gepennt. Sorry. 400ms Periode sind ja 2,5Hz. Das ist also ganz richtig so. Also alles OK so. Kein Fehler.
Tja. Jetzt hatte ich gerade einen Hänger. 2,5Hz lassen sich natürlich nicht mit Dauern von 2s in Verbindung bringen. Moment. Ich beantworte gleich Deine Frage. Erstmal eine Tasse Kaffee.
Günter schrieb: > TeilerUndHerrscher schrieb: >> Hm. Hast Du ein Oszilloskop? >> >> Falls nicht: Auf welche Weise hast Du die tatsächliche Blinkfrequenz >> festgestellt? Es geht nur darum wie genau die Angabe wohl vermutlich >> ist. >> Faktor 10 ist eher ungewöhnlich. Zu erwarten wäre eher irgendeine 2-er >> Potenz. > > Nur pi*Daumen. Ich werde mich morgen mal ein Oszilloskop besorgen bei > einem Kollegen. Ein Frequenzzähler würde auch reichen. Da an sich Deine Schätzung nicht in Frage steht, ist das nicht ganz so wichtig. Es würde halt noch eine Information mehr geben. > welche Compiler und Lib-Versionen dazu geliefert werden. >> Aber um das zumindest mal grob einschätzen zu können, wäre es gut >> Compiler-Version und die Version der avr-lib zu kennen. > > Kannst du mir eben sagen, wo man das nachsehen kann in Atmel Studio? Die 7-Version weicht von dem was ich kenne (Version 4) ab. Aber die Compilerversion müsstest Du sehen, wenn Du ein "Rebuild" startest. Die Version der lib müsstest Du vermutlich in den Einstellungen des Studios bzw. den Projekteinstellungen als Teil des Pfades oder einer Datei sehen. Alternativ kannst Du Dir mal die Dateien in dem Library-Pfad anschauen. Vielleicht auch ein README oder sonst ein Textfile.
Man muss auch sagen, dass der Code selbst und Dein Screenshoot keinen Anhaltspunkt geben, warum die Periode so lange ist. An sich sollte das gehen. Hattest Du vorher mal eine Version mit längerer Periodendauer geschrieben und getestet? Kann es sein, dass Du versehentlich, das falsche hex-file geflasht hast? Vielleicht überprüfst Du das mal.
vielen Dank für die Informationen und die Tipps... ich werde morgen im Zuge der Oszilloskop-Mission allem nachgehen und mich zurückmelden. Genieß den Kaffee, ich wünschte das könnte ich gerade auch :-) Bis morgen
TeilerUndHerrscher schrieb: > Pete K. schrieb: >>>#define F_CPU 1000000UL >> >> Das gehört in das Makefile bzw. die Settings im Studio und NIE in ein .c >> oder .h File. > > Wärst Du so nett und gibst eine Begründung dafür? > Funktioniert es andernfalls garnicht oder ist das eine Stilfrage oder > geht es um etwas anderes? Es geht darum, dass ALLE Files mit dem gleichen Wert übersetzt werden. Du willst das ja auch nicht in delay.h mit rübernehmen und in andere Files.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.