Hallo, Ich spiele gerade mit meinen Weihnachtsgeschenken und versuche rein spasseshalber mal einen einzelnen, möglichst kurzen TTL Puls zu erzeugen. Ich habe einen Atmega1284P mit 20MHz Quarz vor mir. Mit BASCOM und "Pulseout Portb , 5 , 1" komme ich auf 300ns, mit Portb.5 = 1 Portb.5 = 0 schaffe ich 100ns. Ich würde nun gerne mal inline Assembler mit Bascom probieren, damit müsste das doch noch ein bisschen schneller gehen? Leider habe ich keine Ahnung von Assembler, könnte mir da jemand auch die Sprünge helfen? Der Port steht auf Ausgang, der Pin5 auf 0, ich möchte lediglich 2x toggeln. Hat jemand Lust, mir einen kurzen Tipp zu geben? Ach ja, dann würde mich noch interessieren, auf welche Zeiten man so kommt, wenn man an einem Monoflop den Ausgang auf Reset legt. Das dürfte doch auch ganz gut gehen, oder? Danke!
Kürzer geht es mit 2 OUT Befehlen in Folge: IN R16, PORTB LDI R17, 0x20 EOR R17, R16 OUT PORTB, R17 OUT PORTB, R16 Ob Bascom im Inline-ASM die Angabe PORTB richtig umsetzt weiss ich nicht. Oder mit einem Timer.
:
Bearbeitet durch User
NanoSekündler schrieb: > Portb.5 = 1 > Portb.5 = 0 > schaffe ich 100ns. Schneller gehts auch mit inline-Assembler nicht. 20MHz -> 50ns/Takt SBI/CBI brauchen 2 Takte. Auf 50ns (1Takt) kommst du mit OUT P,Rr. Beschreibt allerdings den ganzen Port.
Mit inline ASM kommt man noch auf 1 Taktzyplus oder 50 ns. Das geht dann mit Befehlen wie etwa In R16,portb ANDI R16,255-32 ; bit 5 löschen MOV R17,R16 ORI R17, 32 ; Bit 5 setzen OUT portb,R16 (ggf. nicht nötig) OUT portb,R17 OUT portb,R16 Damit wird dann allerdings immer ein ganzer Port auf einmal gesetzt. Deshalb die Vorbereitung um den Rest zu erhalten.
H.Joachim S. schrieb: > Auf 50ns (1Takt) kommst du mit OUT P,Rr. Beschreibt allerdings den > ganzen Port. Dann einfach mal in das PINx Register schreiben zum toggeln.
A. K. schrieb: > Ob Bascom im Inline-ASM die Angabe PORTB richtig umsetzt weiss ich > nicht. Hm, anscheinend nicht. Zumindest tut sich am Pin nix. H.Joachim S. schrieb: > Schneller gehts auch mit inline-Assembler nicht. > 20MHz -> 50ns/Takt > SBI/CBI brauchen 2 Takte. Klingt logisch! H.Joachim S. schrieb: > Auf 50ns (1Takt) kommst du mit OUT P,Rr. Beschreibt allerdings den > ganzen Port. Wie geht das dann? Komme gerade noch nicht dahinter... Aber ich versuche weiter, eure Vorschläge umzusetzen!
NanoSekündler schrieb: > Ach ja, dann würde mich noch interessieren, auf welche Zeiten man so > kommt, wenn man an einem Monoflop den Ausgang auf Reset legt. Das dürfte > doch auch ganz gut gehen, oder? Nope. War wohl kein Datenblatt beim Weihnachtsgeschenk dabei. Solltest Du reklamieren. Stichwort: Pulse width on RESET Pin Du kannst natürlich einen Ausgangspin direkt auf einen Monoflop geben und dann ist die Pulslänge nur noch durch den Monoflop begrenzt. Also was soll die Spielerei mit dem AVR? 50ns ist Minimum und fertig.
NanoSekündler schrieb: > Ich spiele gerade mit meinen Weihnachtsgeschenken und versuche rein > spasseshalber mal einen einzelnen, möglichst kurzen TTL Puls zu > erzeugen. Wäre da die PWM Logik nicht besser geeignet? Minimale Pulsbreite und Interrupt aktivieren. Nach dem ersten Interrupt die PWM wieder ausschalten. Müsste so doch gehen!?
Frank schrieb: > Wäre da die PWM Logik nicht besser geeignet? Die Counter laufen auch nur mit maximal dem System-Takt. Es gibt ein paar wenige AVR mit PLL, da kann der Peripheral-Clock bis zu 64 MHz hoch sein, etwa beim Tiny45. Ich bin aber nicht sicher, ob der Timer dann auch entsprechend schnell mit den Pins wackeln kann.
:
Bearbeitet durch User
Rudolph R. schrieb: > Dann einfach mal in das PINx Register schreiben zum toggeln. Genau. Bei allen modernen AVRs (die eben dieses Feature unterstützen) ist genau das die effizienteste Implementierung.
Rudolph R. schrieb: > Es gibt ein paar wenige AVR mit PLL, da kann der Peripheral-Clock bis zu > 64 MHz hoch sein, etwa beim Tiny45. > Ich bin aber nicht sicher, ob der Timer dann auch entsprechend schnell > mit den Pins wackeln kann. Kann er natürlich, allerdings nur im CTC- oder PWM-Mode über die OCx-Pins. Genau das ist doch den Sinn der Sache, ansonsten wäre sie doch vollkommen nutzlos... Tsss...
c-hater schrieb: > Kann er natürlich, allerdings nur im CTC- oder PWM-Mode über die > OCx-Pins. Genau das ist doch den Sinn der Sache, ansonsten wäre sie doch > vollkommen nutzlos... Ah, vorsichtig, die PLL ist zwar schon dafür da einen höheren Takt der PWM zu ermöglichen, aber ob da 15,6 ns Impulse raus kommen können ist noch ein bisschen was anderes als Impulse deren Länge um 15,6 ns varieren können. Rise und Fall Zeiten finde ich im Datenblatt vom ATTiny45 jedenfalls gerade nicht und 0ns werden es eher nicht sein.
der m1284p soll auch noch mit 22MHz (bis24MHz im Einzelfall) gut gehen wenn die Spannung gut 5V ist. Noch kürzer ginge doch durch Laufzeit über ein EXOR, dann würde eine Flanke von low/high oder umgekehrt einen Puls liefern, klassische Frequenzverdopplerschaltung, der Impuls ist dann so breit wie die Laufzeit. https://upload.wikimedia.org/wikipedia/commons/1/1a/Frequenzverdoppler_mit_XOR.png weitere Impulse könnte man ja später disablen mit einem Gatter.
Rudolph R. schrieb: > aber ob da 15,6 ns Impulse raus kommen können ist > noch ein bisschen was anderes als Impulse deren Länge um 15,6 ns > varieren können. Geht. Ich habe aus einem ATtiny45 schon 32MHz rausgekriegt. Die Flanken sind nicht so ruppig wie die eines 74AC00, aber es blieb genug vom Signal übrig - soweit sich das mit einem 100MHz Scope beurteilen lässt.
:
Bearbeitet durch User
So, dank Lurchi bin ich nun auf gut 50ns gekommen, sehr schön. Siehe Bild. Timm T. schrieb: > Also was soll die Spielerei mit dem AVR? 50ns ist Minimum und fertig. Wie gleich zu Anfang erwähnt ist das hier eine reine Spielerei ohne konkretes Ziel. Es gibt ungefähr 3 Tage im Jahr, an denen ich mich sowas hingeben kann, heute ist so einer. Was dagegen? 50ns sind ein Minimum bei 20MHz, in der Tat. Evtl. dengel ich heute Nachmittag mal einen 22,xx oder 24MHz Oszillator an den Mega und schaue, wie stabil das noch läuft. Weitere Möglichkeiten werden übrigens hier diskutiert: Beitrag "Pulsgenerator <50ns"
Interessant, dass man auch bei 50ns Pulsen noch ein schwaches "Blitzen" einer roten LED wahrnehmen kann. Interssant wäre ja, ob die LED wirklich "voll" leuchtet und/oder ob sie "viel" Länger nachleuchtet... Kennt da jemand ungefähre Richtwerte, was das Auge/ Gehirn noch wahrnimmt? Leider hab ich gerade weder ein DB zur LED noch zum Auge ;) Irgendwo hab ich noch eine BPX irgendwas rumliegen...
Ich habe mal versucht einen Pulser mit LEDs zu bauen und habe die mit 40MHz und 8ns langen Pulsen, mit 2,5ns rise und fall time gepulst. Beobachtet habe ich das Licht dann mit einem Photomultiplier und die Pulse aus dem Photomultiplier waren etwa 10ns lang (Fußbreite). Soll heißen, die LED leuchtet nicht wirklich nach. Allerdings sollte man die LED schon sorgfältig auswählen wenn man immer gleiche Pulse haben möchte, denn das schaffen nur die wenigstens LEDs. Bei den meisten LEDs schwanken die Pulshöhen extrem (Ein Faktor 10 in der Amplitude ist nicht ungewöhnlich).
NanoSekündler schrieb: > Interssant wäre ja, ob die LED wirklich > "voll" leuchtet und/oder ob sie "viel" Länger nachleuchtet... Die leuchtet so lange nach, bis die Ladungsträger aus der aktiven Zone ausgeräumt sind. Das hängt also von der Kapazität der LED, der Treiberelektronik (hier AVR-Ausgänge) und den fließenden Strömen ab. Mit entsprechendem Aufbau, Kurzschließen der LED oder negativer Sperrspannung erreicht man schon ns. Bei Dir wird das begrenzende der hoffentlich vorhandene Vorwiderstand sein, der ein schnelles Ausräumen der Zone verhindert. > Kennt da > jemand ungefähre Richtwerte, was das Auge/ Gehirn noch wahrnimmt? Das Auge nimmt auch noch 500ps eines (per Fluoreszenzfarbstoff, im einfachsten Fall ein weißes Blatt Papier gewandelten) Stickstofflasers wahr. Das Auge arbeitet integrativ, egal wie kurz die Lichteinwirkung ist, sobald genügend Photonen eintreffen, wird es wahrgenommen.
Die LEDs sind unteschiedllich schnell. Es gibt einige rote, die recht langsam sind, kaum schneller als 1 µs und blaue, die sehr schnell sind - deutlich unter 1 ns. Das hat nicht direkt mit der Farbe zu tun, sondern der Lebensdauer der Ladungsträger. Wenn man keinen so schnellen Fotodetektor hat, kann man sich auch die "Reverse recovery" curve ansehen, also wie schnell die Diode von leitend in sperrend über geht.
Thomas Z. schrieb: > Bei den meisten LEDs schwanken die Pulshöhen extrem (Ein Faktor 10 in > der Amplitude ist nicht ungewöhnlich). Das liegt nicht an der LED, sondern am PMT. Der verstärkt bei kleinen Photointensitäten stochastisch: Ein Photon schlägt ein Elektron aus der ersten Elektrode. Das Elektron wird zur nächsten Elektrode beschleunigt und schlägt dort ein weiteres, oder auch zwei, oder gar keins heraus. Durch die Multiplikation an den Elektroden fällt das Signal entsprechend schwankend aus. Bei hohen Photonenströmen (für die man einen PMT eigentlich nicht verwendet) mittelt sich das statistisch raus. Bei niedrigen Photonenzahlen bzw. kurzen Pulsen wirst Du halt ein Opfer der Stochastik.
Beitrag "Re: Kürzest möglichen Puls mit AVR bei 20MHz erzeugen" Hm, wie kommt man denn bei 20MHz zu 51,6ns? Liegt das am Prozessortakt oder am Oszi? Mich würde interessieren, wie man die Qualität so einer Messung einordnen kann, also was alles beachtet werden muss und wo ich die Angaben dazu finden kann. Dank!
Temperaturkompensierten Quarz nehmen und nochmal messen!
Timm T. schrieb: > Das liegt nicht an der LED, sondern am PMT. Der verstärkt bei kleinen > Photointensitäten stochastisch: Deshalb sind beim Single-Photon Counting die Pulse sehr ähnlich hoch. Klingt logisch ;-) Man wundert sich, wie schnell die Elektronenanzahl so hoch wird, dass sich die statistischen Effekte kräftig wegmitteln.
> Hm, wie kommt man denn bei 20MHz zu 51,6ns? > Liegt das am Prozessortakt oder am Oszi? Nein das liegt eher am Prozessor. Die Abweichung der Pulsbreite bekommt man durch unterschiedliche Verzögerungen der Einschalt- und Ausschaltzeit und/oder unterschiedlicher Anstiegszeit und Abfallzeit.
Also ist das kein Jitter sondern muss immer dazuaddiert werden? Also hätte man auch 102ns, 152ns usw?
Mich würde es nicht wundern, wenn das auch zum Teil abhängig vom Prozessor-Exemplar ist.
Rolf M. schrieb: > Mich würde es nicht wundern, wenn das auch zum Teil abhängig vom > Prozessor-Exemplar ist. Wohl eher auch Vcc und Temp und Triggerschwelle des Oszi.
Rolf M. schrieb: > Mich würde es nicht wundern, wenn das auch zum Teil abhängig vom > Prozessor-Exemplar ist. Quark, Du siehst doch schon am Oszillogramm, daß der Tastkopf nicht richtig abgeglichen ist. Das sind einfach normale Anstiegs und Abfallzeiten verursacht durch Leitungskapazität, Leitungswiderstand, Ausgangswiderstand des Pintreibers...
@ Timm Thaler (timm-thaler) >> Mich würde es nicht wundern, wenn das auch zum Teil abhängig vom >> Prozessor-Exemplar ist. Mich würde es wundern, denn so hoch sind die Toleranzen der Ausgangsstufen nicht. Bei naminal ca. 5ns Anstiegszeit sollte da kaum mehr als 1ns Toleranz drin sein, eher weniger. >Quark, Du siehst doch schon am Oszillogramm, daß der Tastkopf nicht >richtig abgeglichen ist. Wenn du DAS siehst, bist du ein Hellseher. > Das sind einfach normale Anstiegs und >Abfallzeiten verursacht durch Leitungskapazität, Leitungswiderstand, >Ausgangswiderstand des Pintreibers... Bla. Was hier wirklich klingelt ist eine Induktivität! Was man sieht ist in 1. Linie wildes Klingeln durch eine miese, nicht HF-taugliche Tastkopfanbindung mit zu langer Masseleitung. https://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen
Falk B. schrieb: > @ Timm Thaler (timm-thaler) >>> Mich würde es nicht wundern, wenn das auch zum Teil abhängig vom Kannst Du mal bitte ordentlich zitieren...
@ Timm Thaler (timm-thaler) >>>> Mich würde es nicht wundern, wenn das auch zum Teil abhängig vom >Kannst Du mal bitte ordentlich zitieren... Hab ich doch, es ist eine Ebene höher, es fehlt nur der originale Verfasser.
Bitte 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.