delay für µs

Ja, für den Avr-gcc.

Hab da jetzt gerade zum ersten mal reingeschaut. In der Doku hab ich
nichts gefunden.

In der delay.h steht was von _delay_us(double __us)

Ist es das was ich suche?

Genau! Bei Verwendung der Funktionen bitte den eingeschränkten
Wertebereich achten. Welcher µs-Wert maximal eingegeben werden kann,
ist von der Taktfrequenz abhängig und steht auch in der delay.h drin.

Thanks!

Kannst du mir auch sagen, warum ich immer nur auf 400µs komme, egal
welchen Wert ich eingebe?

Wie hier

PORTB |= (1 << PB0);
_delay_us(20);
PORTB &= ~(1 << PB0);

ergibt einen 400µs High Impuls

F_CPU im Makefile richtig eingestellt? Das muss deiner Taktfrequenz in
Hz entsprechen (z.B. 10000000UL für 10MHz).

Bzw. wenn du nicht das Standard-Makefile verwendest: Wird F_CPU
irgendwo definiert, bevor delay.h eingebunden wird?

F_CPU wird als erstes definiert.


Danach wird erst die delay.h eingebunden

Was hast du für eine Taktfrequenz? Sicher, dass der uC mit dem externen
Takt läuft?

8MHz.

Jup, läuft mit dem externen Quarz. Hab das PWM-Signal gemessen und
daraus die Frequenz berechnet. Passt 100%.

Hallo,

gibt es so eine Funktion auch für den ARM GNU Compiler.
Bisher habe ich zwar eine delay Funktion gefunden die einen
Integerwert als Parameter erwartet. Aber wie bekomme ich
exakte delays in µS oder mS hin.

Frage mich langsam wirklich, warum so viele Leute übersehen, dass es
hier ein extra GCC-Forum gibt...

> Kannst du mir auch sagen, warum ich immer nur auf 400µs komme,
> egal welchen Wert ich eingebe?

Optimierungen aus?

Welche Optimierungen?

Compiler-Optimierungen. Switch -O... auf der Kommandozeile.

warum du immer nur auf 400µs kommst kann ich dir vermutlich sagen, die
funktion delay_us ist mist, davon handeln hier schon ne menge thrads,
die setzt die parameter per gleitkommaopreationen um und das ist nun
mal grottenlangsam hier ein thread mit dem selben thema

http://www.mikrocontroller.net/forum/read-2-370568.html#new

@Qwerty: Sorry, aber was oder wo ist Switch -O... auf der
         Kommandozeile


@Karl-Heinz: Hallo Karl-Heinz, hab versucht mich über die delay-
             Funktion zu informieren. Hab mir auch das Header-File
             angeschaut aber nicht ganz verstanden. Die maximale
             Länge in µs ist klar, nur was ist die kürzeste?
             Bräuchte 6µs, ist das mit der delay-Funktion möglich?

@Jahn:
Das was Du schreibst, stimmt so nicht! Wenn man die
Compiler-Optimierung einstellt, werden alle Gleitkommaoperationen zur
Compilerlaufzeit durchgeführt. "Langsam" ist völliger Käse. Bei mir
(und auch bei denjenigen, die in dem von Dir oben verlinkten Thread
zunächst Probleme damit hatten) funktionieren die _delay_xx-Funktionen
tadellos!

@Joshi:
Klar ist das möglich, vorausgesetzt, Dein µC läuft mit einer
Taktfrequenz, die so bemessen ist, dass sich die 6µs noch durch eine
ganzzahlige Anzahl von Durchläufen bewerkstelligen lassen. Wenn Dein µC
mit nur 1MHz läuft, dürfte es da allerdings schon Probleme geben... Das
machste dann besser tatsächlich mit Inline Assembler und nop.

Der µC läuft mit einer Taktfrequenz von 8MHz.

Mit einem Programm wo nur die delay-Funktion läuft, komm ich locker auf
nano_Sekunden.

Doch wenn ich die Funktion in mein Programm einbaue, wo noch zwei
Interrupts(Compare und UART-Receive)laufen + die Initialisierungen dann
schafft er gerade mal 60µs.

...???

Wenn da natürlich ein Interrupt dazwischenhaut, isses eh Essig mit
präzisen delay-Routinen. Und je nachdem, was in den ISRs gemacht wird,
ist das kein Wunder, dass es hakt. Versuch mal, vor dem delay die
Interrupts zu deaktivieren und danach wieder zu aktivieren, dann sollte
das auch funktionieren.

Dann taucht aber das Problem auf, dass mir de Takt für das Signal fehlt.


Erzeuge mir nämlich mit dem Timer Interrupt ein Taktsignal. Ab einer
bestimmten Stelle des Taktsignals sollen dann zeitgleich ein paar
Impulse von 6µs Länge kommen.

ne andere Möglichkeit gibt es nicht?

Wenn Du mit einem relativ langsam laufenden Timer das ganze triggerst,
was hindert Dich daran, wenn es so weit ist, dass die "paar Impulse"
raus sollen, die Interrupts kurzzeitig zu deaktivieren? Anscheinend hat
die Impulserzeugung ja oberste Priorität, gell?

@Joshi: Die Kommandozeile ist der Befehl, der den avr-gcc startet. Also
"avr-gcc foo bar blah blubb blarf ....". Das "foo bar blah blubb
blarf..." sind Dateinamen, Parameter, Optionen, Schalter, die dem
Compiler sagen was er wie zu tun hat. Unter anderem kann man dort auch
die Option -O angeben, gefolgt von einer Kennung für die gewünschte
Optimierung, also z.B. -OS für eine Size-Optimierung (möglichst kurzer
Code), -O3 für möglichst schnellen Code, -O0 zur Abschaltung aller
Optimierungen.

Für die effektive delay-Nutzung müssen Optimierungen eingeschaltet
sein, da sonst das schon erwähnte Floating-Point-Problem auftritt.

In der Doku ist IMHO übrigens erwähnt, dass die Delay-Routinen nur dann
präzise arbeiten, wenn die CPU nicht zwischendurch noch ISRn abarbeitet.
Also musst du entweder die Interrupts ausschalten, oder einen
Hardware-Timer nehmen, oder mit der Ungenauigkeit leben.

>>Also musst du entweder die Interrupts ausschalten, oder einen
Hardware-Timer nehmen, oder mit der Ungenauigkeit leben.

Oder einfach besser programmieren lernen... Warteschleifen lassen sich
eigentlich immer umgehen.

"Warteschleifen lassen sich eigentlich immer umgehen."

Was für eine Technik verwendest du für das Timing des E Signals eines
HD44780-LCDs oder des 1-Wire-Busses?