Atmel Studio 7, auch der Suche nach CKDIV8

hier ein Bildschirmabgriff meiner Fuse-Einstellungen (Anhang)

>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.

>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.

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