delay(nanosekunden)?

Nein, tut es nicht.

Rechne dir aus, wieviele Takte deine Zeit lang ist (das werden bei ns 
nicht allzu viele sein) und bau enstprechende Pausen.

Gruß
Lasse

Nein.
Du kannst einen Timer verwenden, aber bis auf den unteren 
Nansosekundenbereicha aufzuloesen ist mit einem AVR nicht moeglich. Wie 
auch, eine einzige Taktperiode ist bei 20MHz Systemtakt 50ns lang.

Damien schrieb:
> Geht das auch so?

Wenn du die Zeit die, die while-Schleife benötigt mit einrechnest 
(ASM-Listing ansehen und Takte zählen) könnte dies durchaus 
funktionieren. Wenn du nicht unbedingt sehr lange Verzögerungen 
brauchst, dann tut es auch ein unsigned char.
Welchen Compiler verwendest du?
Michael G. schrieb:
> Wie
> auch, eine einzige Taktperiode ist bei 20MHz Systemtakt 50ns lang.
Stimmt, aber manche AVRs kommen mit einer PLL so weit ich weiß auf bis 
zu 64MHz Timertakt.

Damien schrieb:
> allerdings suche ich momentan nach einer delay(nanosekunden)- Funktion.
Sag doch einfach mal, warum und wofür du so etwas brauchst...

Zum Hintergrund: wenn du das Datenblatt eines uC mal gelesen hast (das 
ist eine interessante Lektüre, besonders für jemanden, der so einen uC 
verwendet), dann hast du auch gesehen, dass der alle Aktionen 
taktgesteuert ausführt. Jeder (Assembler-)Befehl braucht eine bestimmte 
Anzahl Takte. Und mit einem 10MHz-Takt sind das dann schnellstenfalls 
100ns (z.B. für einen NOP). Weil ja auch die Befehle vor und nach dem 
NOP Zeit verbrauchen, kommst du aber niemals tatsächlich auf so eine 
kurze Zeit. Und vor allem: du kannst nicht sagen: ich möchte eine 
Verzögerung um 266ns...

Rolf Magnus schrieb:
> Luk4s K. schrieb:
>>> Wie auch, eine einzige Taktperiode ist bei 20MHz Systemtakt 50ns lang.
>> Stimmt, aber manche AVRs kommen mit einer PLL so weit ich weiß auf bis
>> zu 64MHz Timertakt.
>
> Ja, und was sollte das bringen? Damit kann man den AVR trotzdem nicht
> mit höherer Auflösung als einen Taktzyklus warten lassen.
Stimmt, macht tatsächlich nur minder Sinn.

>Nur mal 'ne wahrscheinlich doofe Frage: Das zwischen Millisekunden und
>Nanosekunden 10 hoch 6 liegt und Mikrosekunden genau dazwischen, ist
>bekannt?

Offensichtlich nicht, sonst würde man nicht solche Fragen stellen (vor 
allem vor dem Hintergrund, daß ein AVR-Takt üblicherweise bereits 
etliche 10ns braucht - er also ohnehin nicht genauer auflösen kann).
Vermutlich meinte er eher µs - das könnte ich mir noch so einigermaßen 
als sinnvoll vorstellen. Wenn es wirklich um ns geht, dann machen es 
vermutlich auch reine nops, die eine Verzögerung entsprechend der 
Taktperiode bwerkstelligen.

Jens G. schrieb:
> Offensichtlich nicht, sonst würde man nicht solche Fragen stellen
Jaja, Rätselraten ist alles, was uns bleibt...  ;-)
Lothar Miller schrieb:
> Damien schrieb:
>> allerdings suche ich momentan nach einer delay(nanosekunden)- Funktion.
> Sag doch einfach mal, warum und wofür du so etwas brauchst...

Damien schrieb:
> Dabei soll die Frequenz 300 Mhz betragen(diese muss später erhöht werden)

Na dann besorge dir mal einen mikrocontroller mit 1 bis 2 GHz CPU Takt. 
Denn den wirst du so ungefähr je nach Anwendung benötigen. (Mal davon 
abgesehen, was dort am Pin für ein "Rechteck-"Gemüse bei 300MHz 
rauskommt)

Ich denke, es ist Zeit, die Popcorn in die Mikrowelle zu legen... 300Mhz 
Dreieck in Software, das ist ganz grossartig und auch Richtung weisend. 
Thumbs up!

Damien schrieb:
> Nein^^ 300Hz :D

Naja, 300Hz Rechteck wäre kein Problem. Aber Dreieck mit 256 Schritten? 
Das halte ich schon ohne delay Funktion for hart an der Grenze des 
überhaupt machbaren.
Welche Taktfrequenz hat der Mikrocontroller? Wieviel Takte braucht der 
so pro increment und branch instruktion?

Schreibe mal was über die Anwendung. Mag sein, dass eine schnuckelige 
DDS in Software genau das Richtige für Dich ist.

Damien schrieb:
> bei 'branch' verstehe ich nicht mehr viel :(

Du solltest unbedingt die Assemblersprache deines PIC lernen und 
erstmal anfangen auszurechnen wieviele Befehle du zur Verfügung hast um 
deinen Takt überhaupt zu erzeugen.
Das werden nicht viele sein.
Dann musst du ausrechnen wieviele Befehle du mindestens brauchst um 
einen Schritt zu erzeugen. Das werden einige sein.

Deine Anwendung befindet sich definitiv sehr nah an der oberen 
Leistungsgrenze des Mikrokontrollers und die 10khz Anwendung (mit 256 
Schritten) ist mit Sicherheit über der Leistungsfähigkeit des 
Controllers.

Rage schrieb:
> Hmm, würde es Sinn machen, nur 128 Schritte pro Amplitude zu nehmen?

Das kannst nur du wissen, wie genau dein quantisiertes Dreieck an einem 
realen Dreick sein muss.