ATtiny 13; 700kHz anstatt 1Mhz

[Paul (Gast)]

Hallo Forum,

ich versuche gerade einen Taktgenerator mit einem ATtiny 13 zu 
erstellen.

Ich arbeite mit
AVR Studio 5
AVRDUDE
mit einem Arduino (AVRISP) als Programmer.

Fuses Lfuse: 0x72 Hfuse: 0xFF

#define F_CPU 9600000
#include <avr/io.h>
#include <util/delay.h>

int main(void)
{

  DDRB = 0b001000;

    while(1)
    {

         PORTB = 0b001000; _delay_us(0.5);
         PORTB = 0b000000; _delay_us(0.5);
    }

  return 0;
}

Leider liegt am Ausgang dann ein Signal von 700khz anstatt 1Mhz an.
An was könnte das liegen?

Im unteren Frequenzbereich z.B. f = 100kHz geht alles wunder bar.

Grüße
Paul

[Oliver J. (skriptkiddy)]

Nimm einen Timer.
Mit den Delay-Funktionen kann man nicht so ohne weiteres einen korrekten 
Takt erzeugen. Besonders nicht im Bereich von einem 10-tel des 
CPU-Taktes.

Gruß Oliver

[Hannes L. (hannes)]

Paul schrieb:
> Leider liegt am Ausgang dann ein Signal von 700khz anstatt 1Mhz an.
> An was könnte das liegen?

Vermutlich daran, dass Dein Code die Delays von einer halben 
Mikrosekunde nicht schaffen kann. Also dass der Aufruf der Funktion 
schon länger dauert. Schau Dir den erzeugten ASM-Code an und berechne 
anhand der Befehlstabelle die Ausführungszeit.

...

[Oliver J. (skriptkiddy)]

9.6 MHz lässt sich außerdem nicht auf 1 MHz teilen.

[Paul (Gast)]

Was mich wundert:

verwendet man das Eclipse Plug in, gleicher Code, gleiche Fuseses.

--> 1MHz am Ausgang.

Das ist es, was mich verwirrt.
Liegt es womöglich irgend wo an den Einstellungen vom AVR Studio 5?

Danke für die Antworten
Grüße

[Martin (Gast)]

Paul schrieb:
> verwendet man das Eclipse Plug in, gleicher Code, gleiche Fuseses.
> --> 1MHz am Ausgang.

Und wie unterscheidet sich der erzeugte Assemblercode der beiden 
Versionen?

[(prx) A. K. (prx)]

Paul schrieb:

> ich versuche gerade einen Taktgenerator mit einem ATtiny 13 zu
> erstellen.

Geht bei derart engen Zeitbedingungen mit einem Timer besser.

[Εrnst B. (ernst)]

Paul schrieb:
> verwendet man das Eclipse Plug in, gleicher Code, gleiche Fuseses.
>
> --> 1MHz am Ausgang.

Paul, nimm mal die beiden _delays komplett raus, lass nur die Schleife 
mit den Portzuweisungen.
Dann miss nochmal nach, und überleg dir, warum du nicht auf ∞ MHz 
kommst.
Wenn dir das klargeworden ist, überleg dir nochmal, ob dein Quelltext 
zwingend 1MHz erzeugen soll, oder ob nicht auch 700kHz oder z.B. auch 
1Hz exakt dem im C-Sourcecode formuliertem Programm entspricht.

[Paul (Gast)]

Εrnst B✶ schrieb:
> warum du nicht auf ∞ MHz
> kommst.


Hallo Ernst,

ich nehme an, dass jeder Befehl für sich selbst Zeit benötigt um 
abgearbeitet zu werden. Das hat natürlich zur Folge, dass sich die ganze 
Sache mit den delays ebenso verschiebt --> Periodendauer geht nach Oben, 
Frequenz geht nach unten.
Richtig?

[Hannes L. (hannes)]

Richtig!

Und da der AVR kein C kann, kannst Du das nicht so ohne Weiteres auf 
Hochsprachenbasis schätzen. Du musst Dir also den ASM-Output Deines 
Compilers ansehen, denn das kann der AVR (in Form von Maschiencode) 
exakt 1 zu 1 abarbeiten. Die Liste, welcher ASM-Befehl wieviele Takte 
braucht, findest Du im Datenblatt (Instruction Set Summary).

...

[Karl H. (kbuchegg)]

Paul schrieb:
> Was mich wundert:
>
> verwendet man das Eclipse Plug in, gleicher Code, gleiche Fuseses.
>
> --> 1MHz am Ausgang.
>
> Das ist es, was mich verwirrt.
> Liegt es womöglich irgend wo an den Einstellungen vom AVR Studio 5?

gleiche Optimizer-Einstellungen?
Gleiche Compiler Version?

[Jörg W. (dl8dtl) (Moderator)]

Paul schrieb:
> Liegt es womöglich irgend wo an den Einstellungen vom AVR Studio 5?

Dem Vernehmen nach schaltet AVR Studio 5 nicht freiwillig die
Optimierung an.  Dann sollte das auch nicht weiter verwundern,
denn dann gibst du dem Prozessor in jedem Durchlauf noch einen
Haufen Gleitkommarechnungen mit als Hausaufgaben.

Man könnte auch ketzerisch sein: bleib doch lieber bei Eclipse,
wenn es ohnehin besser funktioniert. ;-)

[Paul (Gast)]

ungern. Ich würde gerne wissen wo der Fehler liegt.

Ich habe die Optimizationeistellung auf "Optimize for size (-Os)" und 
"Pack Structure members together" + "Allocate only as many bytes needed 
by enum types"

[Klaus D. (kolisson)]

Paul schrieb:
> Optimize for size

ist das nicht der Todfeind von Speed ?

k.

[Jörg W. (dl8dtl) (Moderator)]

Paul schrieb:

> Ich habe die Optimizationeistellung auf "Optimize for size (-Os)" und

Dann ist das Ergebnis seltsam.

> "Pack Structure members together"

Die (bei einem AVR) völlig unsinnig ist, aber das hat den Atmel-
Entwicklern noch keiner gesagt. ;-)

> + "Allocate only as many bytes needed
> by enum types"

Naja, finde ich auch unsinnig.  Sollte man, wenn man's unbedingt
haben will, lieber als attribute beim jeweiligen enum schreiben.

Klaus De lisson schrieb:
>> Optimize for size
>
> ist das nicht der Todfeind von Speed ?

Beim AVR nicht, da ist geringere Codegröße in erster Linie auch
schneller (weil weniger Befehle halt weniger Zeit brauchen).
Lediglich durch -O3 (aggressives Entrollen von Schleifen und
dergleichen) kehrt man das dann noch um, da wird der größere
Code dann wirklich schneller.

Wichtig für die delay-Funktionen ist aber ohnehin nur, dass überhaupt
ein -O (anders als -O0) aktiv ist.