Hallo, Ich bin derzeit in der Planung für ein kleines 1 Kanal DSO. 80MS/s 5Mhz Bandbreite 32Kbyte Speichertiefe Gesteuert wird über einen Mega32 4x4bit synchron Zähler zählen die Adressen für ein 32kbyte SRAM. Das überschüßige MSB des letzten Zählers sorgt als 'Interrupt' am Mux für sofortiges abschalten des Takts und somit für ein Beenden des Meßvorgangs. Der Samplevorgang ist also relativ autark. Der Mega32 braucht nur die Dauer einer Messung abwarten. Danach wird der ADS831 mittels Buskoppler vom Datenbus getrennt und der Mega32 liest die Daten mit 500khz aus dem SRAM und schickt sie an den PC/LCD. Anschließend kurzer Reset der Zähler und es geht von vorne los. Bisher steht der Digitalteil und eine Eingangsbeschaltung des ADC wie sie als Referenzdesign im Datenblatt zu finden ist. Was noch fehlt ist der Eingangsabschwächer bzw Verstärker um für jeden Meßbereich ein ADC Eingangssignal von 2Vpp zu erreichen sowie die Software für PC und uC. Bevor ich weiter mache würde ich gerne wissen ob die Schaltung überhaupt ihren Zweck erfüllen würde. Dazu habe ich mal den Schaltplan angehängt. Auf einen Trigger habe ich bisher verzichtet da ich ihn nicht unbedingt brauche und die Sache für den Anfang nicht zu kompliziert werden soll. mfg Andre
Angehängte Dateien:
-
oszi.png
39 KB
Welchen HC74 verwendest du? Mit dem von Philips/NXP hast du die Latte der maximalen Taktfrequenz knapp gerissen:
1 | fmax maximum clock frequency 76 MHz / 5V |
Bei dem von OnSemi sogar sehr deutlich: famx= 30MHz Gleiches gilt für den 74HC160 :-o Funktioniert dein SRAM mit derart kurzen Zugriffszeiten? Passt das /WE Timing an deinem SRAM? Ich habe da so meine Zweifel... Pass beim Verdrahten/Layout sehr gut auf: 80/40/20 MHz sind HF. Bei allen Logikbausteinen und beim RAM fehlen Blockkondensatoren (10-100nF).
Des Buskoppler MC kannst du dir sparen, das kriegt der MC auch selber zustande. Das 74HCs hier sämtlich fehl am Platz sind hat Lothar schon erwähnt. ADC wie RAM sind zeitlich an ihrer Grenze (ist das 10-12ns RAM?) und haben somit keinerlei Reserve. Wenn das ohne irgendwelches Tuning über Delaylines abgeht wär's fast ein Wunder. Plan lieber mal eine Inverterkette dafür ein, damit du damit rumspielen kannst. @Lothar: Die Cs verstecken sich links unten.
> @Lothar: Die Cs verstecken sich links unten. Na gut, blind also auch schon... :-/ > @Lothar: Die Cs verstecken sich links unten. Ja, und dort wird sie der Layouter auch auf der Platine platzieren :-o (kein Witz, alles schon passiert...)
Hallo, Buskoppler hat A. K. (prx) schon gesagt. Ansonsten einfach mal bei mir reinschauen und vergleichen... http://www.avr.roehres-home.de/logikanalyzer/index.html Den ADC vorn ran, Triggerlogik ist dann auch gleich da. Ram muß 12ns Cache-Ram sein bei 80MHz, die haben das dazu passende Timing beim Write ohne Delay-Lines suchen zu müssen. Gruß aus Berlin Michael
Beim ADC solltest du ein bischen auf die Versorgung achten, evtl. bischen entkoppeln. Die 74ACs und das RAM werden dir ganz hübsch in die Versorgung spucken.
Das der Mega32 von Werk aus Tristate kann wusste ich noch nicht. Danke für den Tip. Alle anderen Punkte sollten kein Problem sein. Der laut Schaltplan verwendete HC74 ist ein SN74ACT74 von TI und macht 125MHz. Die Zähler kommen auf minimum 91MHz und der SRAM ist natürlich ein 12ns Typ. Ich habe also bei allen kritischen Parts noch ein wenig Spiel nach oben. Mit welcher Sprache bekomme ich eigentlich am einfachsten eine PC Software zusammen geschustert? Mit GUIs habe ich bisher keinerlei Erfahrung. Ich müsste halt den COM Port auslesen/beschreiben können und den Graphen zeichnen. Gibts da was klickibunti einfaches von MS? ;)
>Ich müsste halt den COM Port auslesen/beschreiben können und >den Graphen zeichnen. Gibts da was klickibunti einfaches von MS? ;) Excel
Andre I. schrieb: > Das der Mega32 von Werk aus Tristate kann wusste ich noch nicht. Aber dass er die Pins auf Input schalten kann wusstest du bestimmt schon. Was ist daran anders? > Schaltplan verwendete HC74 ist ein SN74ACT74 von TI und macht 125MHz. Wenn du 74AC(T) verwenden willst, warum schreibst du dann zur Verwirrung der Leser ins Schaltbild lauter 74HC Typen rein? Ein 74HC ist kein 74AC. > Ich habe also bei allen kritischen Parts noch ein wenig Spiel nach oben. Ein 12ns SRAM hat bei 80MHz (12,5ns) keinen nennenswerten Spielraum mehr. Ein 80MHz ADC auch nicht. Oder siehst du die als unkritisch an?
Ich mach sowas immer mit C#, damit ist das Auslesen des COM-Ports ein Kinderspiel.
Weil Eagle nicht die passenden Bauteile hat und es spät war. Ich habe also schlicht vergessen diese umzubenennen. Von einem ADC der mit 80MS/s angegeben ist erwarte ich schlicht das der auch seine 80MS/s macht. Dafür sorgt schon der Hersteller. Beim SRAM verhält es sich ähnlich. Davon ab sind noch schnellere nicht so einfach zu bekommen. @Michael Ein wenig mehr Oszi GUI darfs schon sein ;) Denke Visual Basic dürfte am unkompliziertesten sein oder? //edit das ging schnell. Dann werde ich mir auch mal die beiden anderen genannten Sprachen ansehen. Danke
Andre I. schrieb: > Von einem ADC der mit 80MS/s angegeben ist erwarte ich schlicht das der > auch seine 80MS/s macht. Dafür sorgt schon der Hersteller. Beim SRAM > verhält es sich ähnlich. Natürlich, aber darum geht es nicht. An der Grenzfrequenz ist das exakte Timing der Signale einigermassen kritisch. Andernfalls wäre man noch nicht an der Grenze. Obwohl jeder für sich die Frequenz schafft kann dennoch das Zusammenspiel aus Multiplexer, Counter, ADC, Puffer und SRAM ein präzises Tuning des Zeitverhaltens erfordern.
A. K. schrieb: > An der Grenzfrequenz ist das exakte > Timing der Signale einigermassen kritisch. Obwohl jeder für sich die > Frequenz schafft kann dennoch das Zusammenspiel aus Multiplexer, > Counter, ADC, Puffer und SRAM ein präzises Tuning des Zeitverhaltens > erfordern. Genau das ist das Problem: Nicht ohne Grund bekommt man oberhalb von 100MHz nur noch synchrone Speicher. WE\ bekommt den invertierten Takt. Somit ist WE\ bei 80MHz nur für etwa 6ns aktiv. Reicht das dem SRAM wirklich aus? Wie schaltest du WE\ eigentlich ab? Das ist doch immer in jeder 2. Takthälfte aktiv, auch beim Auslesen. R2 und R3 kommen mir komisch vor: Erstens ergibt 100nF + 500 Ohm einen schönen Hochpass, zweitens beeinflusst das Signal über die 1k Widerstände bestimmt schön die Referenzspannung des ADCs.
A. K. schrieb: > Andre I. schrieb: > >> Von einem ADC der mit 80MS/s angegeben ist erwarte ich schlicht das der >> auch seine 80MS/s macht. Dafür sorgt schon der Hersteller. Beim SRAM >> verhält es sich ähnlich. > > Natürlich, aber darum geht es nicht. An der Grenzfrequenz ist das exakte > Timing der Signale einigermassen kritisch. Obwohl jeder für sich die > Frequenz schafft kann dennoch das Zusammenspiel aus Multiplexer, > Counter, ADC, Puffer und SRAM ein präzises Tuning des Zeitverhaltens > erfordern. Gut dein Vorschlag wären also Delay Lines. Für das /WE Signal des SRAM waren diese eh geplant. Beim Rest will ich es trotzdem erstmal ohne versuchen. Die Dinger brauchen ja auch Platz und der ist begrenzt
Wiseo sind da eigentlich Dezimalzähler(160er) drin und keine Binärzahler? Durch die Verzögerung des Übertrags von Zähler zu Zähler schafft dieser 16 bit Synchronzähler bei Verwenmdunmg von 74ACT gerade mal 25MHz.
Mein Vorschlag ist, dass du das zeitliche Zusammenspiel erst einmal mit Papier und Bleistift durchspielst. Mal die Signale mit ihren relativen Zeitbezügen (propagation delay, access time, ...) und zeitlichen Randbedingungen (setup/hold time) leidlich massstäblich auf, um zu sehen ob das ganze irgendwie passt.
Helmut schrieb: > Wiseo sind da eigentlich Dezimalzähler(160er) drin und keine > Binärzahler? > > Durch die Verzögerung des Übertrags von Zähler zu Zähler schafft dieser > 16 bit Synchronzähler bei Verwenmdunmg von 74ACT gerade mal 25MHz. Es handelt sich um CD74ACT161 binary Counter.
Angehängte Dateien:
-
oszi.png
38 KB
Ich habe die Bezeichnungen noch einmal im Schaltplan geändert damit diese nicht für ständige Verunsicherung sorgen.. Mir ist übrigens aufgefallen das ich heute morgen im Halbschlaf die falsche Eingangsbeschaltung des ADS aus dem Datenblatt übernommen habe, die hier verwendete ist AC gekoppelt..
Helmut schrieb: > Durch die Verzögerung des Übertrags von Zähler zu Zähler schafft dieser > 16 bit Synchronzähler bei Verwenmdunmg von 74ACT gerade mal 25MHz. Ich kommt dabei auf ~45MHz beim 74AC163 (7+6+6+2,5, Fairchild Datasheet, 25°C), aber für 80MHz langt das jedenfalls nicht. AC ist eher zeitlich besser als ACT.
Andre I. schrieb: > Ich habe die Bezeichnungen noch einmal im Schaltplan geändert damit > diese nicht für ständige Verunsicherung sorgen.. Der '245 sollte auch AC sein, es sei denn du benötigst genau dessen grössere Verzögerung.
Hallo, A. K. schrieb: > Helmut schrieb: > >> Durch die Verzögerung des Übertrags von Zähler zu Zähler schafft dieser >> 16 bit Synchronzähler bei Verwenmdunmg von 74ACT gerade mal 25MHz. Es gibt keine Verzögerung durch den Übertrag. Die Freigabe für den nächsten wird bei Zählerstand 15 gesetzt und der nächste Takt schaltet parallel alle folgenden Zähler um. > Ich kommt dabei auf ~45MHz beim 74AC163 (7+6+6+2,5, Fairchild Datasheet, > 25°C), aber für 80MHz langt das jedenfalls nicht. > > AC ist eher zeitlich besser als ACT. Der 74ACT161 von Fairchild ist mit minimal 115MHz angegeben, das gilt prinzipiell auch für cascadierte. Meine laufen jedenfalls mit 80MHz problemlos. Problematisch ist die Betriebsspannung, da ich vom USB versorge, gibt es an meinem alten thinkpad-Notebook mit ca. 4,7V Spannung bereits die ersten Probleme mit den ACT161 von Fairchild. Am anderen Rechner bei 4,9V dagegen nicht. Gruß aus Berlin Michael
Michael U. schrieb: > Es gibt keine Verzögerung durch den Übertrag. Die Freigabe für den > nächsten wird bei Zählerstand 15 gesetzt und der nächste Takt schaltet > parallel alle folgenden Zähler um. Ich denke schon. Siehe Innenschaltung, TC vom ersten Zähler durchläuft ein Gatter in beiden Zwischenzählern und enabled den letzten Zähler. Bei längerer Kette können sich externe Gatter lohnen (bei 3 nicht, bei 4 evtl. schon). Erster Zähler: CP => TC propagation delay. Die Zähler zwischendrin: CET => TC propagation delay. Letzter Zähler: CET => CP setup time. Die Summe dieser Zeiten muss in einen Takt passen.
Hallo, @A. K. (prx): da hast Du wohl recht. Kann mich da irgendwie auch noch an solche Beispiele bei den 74193 erinnern um die Zeiten zu verringern... Gruß aus Berlin Michael
Hallo, Da ist die Schaltung mit "look ahead carry" abgebildet. Die rennt schneller. http://www.fairchildsemi.com/ds/74%2F74AC161.pdf Vielelicht schaffst du ja damit dann typisch 50MHz. 50MHz ist auch nicht zu verachten für einen Eigenbau. Ansonstemn müsstest du dir halt ein FPGA-Eval-Board von Xilinx kaufen. Da schafft dein Synchronzähler dann bestimmt die 100MHz(200MHz?). Externes RAM brauchst du dort nicht unedingt, falls dir das interne Block-RAM reicht.
Helmut schrieb:
> Vielelicht schaffst du ja damit dann typisch 50MHz.
6+2=8ns, damit sind die 80MHz durchaus drin.
Hallo, 50MHz sind mit 4 Zählern mit 74ACT161 mit Sicherheit drin, meine sind ja auch keine ausgesuchten. 80MHz mit 3 Zählern auch sicher, auch bei Ub 4,7V vom USB. Link habe ich ja oben schon gepostet, das spielt real und stabil, mindestens ein Nachbau der 80MHz-Version spielt auch bei jemand anders. Gruß aus Berlin Michael
Warum ist eigentlich der Eingang AC gekoppelt?
Angehängte Dateien:
-
oszi.png
38 KB
Ich hab die letzten Tage mal ein bisschen weiter gearbeitet. Jetzt fehlt nur noch die Eingangsbeschaltung des ADC und einen Testaufbau steht erstmal nichts mehr im Weg. Ich bin gespannt.
Alexander Schmidt schrieb:
> Warum ist eigentlich der Eingang AC gekoppelt?
Das ist doch für ein DSO ziemlich hinderlich.
das hab ich viele Posts über deinem bereits erklärt und entfernt
nimm doch soweas zB http://www.ssalewski.de/DSO.html.en ps das koppel C hat er wohl aus dem reff desing is halt sehr ungünstig sowas zu nehmen wenn man nicht weiß was es macht VIEL GLÜCK
was ich noch ergänzen bzw. wenigstens die Lötpunkte vorsehen würde, wäre eine Diode vom Reglerausgang zum Reglereingang, ein kleiner Elko am Reglerausgang da viele Regler noch ca. 10-20µF brauchen damit Sie nicht schwingen, hatte gestern erst das Problem mit einem LM2940-T5. Ein kleine Spule/Widerstand und eine Z-Diode kurz vor dem Regler wäre auch noch eine kleine Enstörmaßnahme was dem Regler die Arbeit erleichtert.
Die Zählerkette ist immer noch die alte. Wie Helmut erwähnte geht das mit anderer Verschaltung wesentlich fixer, ohne zusätzlichem Aufwand.
Bei 80 MHz noch mit 100nF die Versorgungsspannung entkoppeln wollen? Ts ts. Die haben doch ihre Resonanzfrequenz schon bei 50 MHz.
Angehängte Dateien:
-
oszilloskop.png
41 KB
wäre das dann so der bessere weg die zähler zu beschalten. ich bin mir nämlich nicht sicher wie ich das /count am ersten zähler verstehen darf. ich bin jetzt mal nach der wahrheitstabelle gegangen.
Hi Andre, warum nimmst du statt der ACT74 Flipflops nicht auch einen weiteren ACT161 als Takt-Teiler? Dann könntest du mit einem Baustein nicht nur /2 und /4 teilen, sondern auch noch /8 und /16. Der ACT151 Multiplexer hat dafür noch genug Eingänge über, du musst nur ein weiteres Portpin am AVR zur Taktauswahl opfen. Aber der Mega32 hat ja auch genug Pins über. Das ganze hat einen einfachen Grund: dein niedrigster Takt sind 20MHz, also 50ns pro Taktperiode. Du kannst 32768 Samples abspeichern, also beträgt die maximale Zeit, die du sampeln kannst gerade mal 1,6ms. (Oder hab ich mich jetzt verrechnet?) Bei Frequenzen unter 610Hz kannst du also nur eine einige Periode darstellenT Mit einem Zähler statt Flipflop kannst du die unterste darstellbare Frequenz zumindest auf 150Hz senken ohne einen weiteren IC zu verlöten. Und die Bestellung der Teile wird auch einfacher ;-) mfg Harri
Andre I. schrieb: > wäre das dann so der bessere weg die zähler zu beschalten. Siehe http://www.fairchildsemi.com/ds/74%2F74AC161.pdf Figure 2. PS: Wenn dein Quarzoszillator CMOS-Pegel liefert, dann nimm 74AC, nicht 74ACT, die haben ein besseres weil symmetrisches Timing.
Harald S. schrieb: > Hi Andre, > > Das ganze hat einen einfachen Grund: dein niedrigster Takt sind 20MHz, > also 50ns pro Taktperiode. Du kannst 32768 Samples abspeichern, also > beträgt die maximale Zeit, die du sampeln kannst gerade mal 1,6ms. > (Oder hab ich mich jetzt verrechnet?) > > Bei Frequenzen unter 610Hz kannst du also nur eine einige Periode > darstellenT > > Mit einem Zähler statt Flipflop kannst du die unterste darstellbare > Frequenz zumindest auf 150Hz senken ohne einen weiteren IC zu verlöten. > Und die Bestellung der Teile wird auch einfacher ;-) > > mfg > Harri Den Takt für die unteren Frequenzen wollte ich eigentlich mit dem Mega32 erzeugen. Dachte da an 500kHz. Damit komme ich von der Bandbreite recht weiter nach unten und habe im AVR noch Zeit für andere Dinge. A. K. schrieb: > Andre I. schrieb: > >> wäre das dann so der bessere weg die zähler zu beschalten. > > Siehe http://www.fairchildsemi.com/ds/74%2F74AC161.pdf Figure 2. > > PS: Wenn dein Quarzoszillator CMOS-Pegel liefert, dann nimm 74AC, nicht > 74ACT, die haben ein besseres weil symmetrisches Timing. Das Datenblatt habe ich für die neue Verschaltung benutzt. Nur /COUNT am CET Eingang des ersten Zähler verstehe ich nicht. Hab das jetzt mal wegen der Wahrheitstabelle auf High Pegel gesetzt. Hoffe das stimmt so
Andre I. schrieb: > Das Datenblatt habe ich für die neue Verschaltung benutzt. Nur /COUNT am > CET Eingang des ersten Zähler verstehe ich nicht. Hab das jetzt mal > wegen der Wahrheitstabelle auf High Pegel gesetzt. Hoffe das stimmt so Ist ein Fehler im Fairchild Datasheet, denn es suggeriert, dass bei 0 gezählt würde und bei 1 nicht, wobei es grad andersrum ist. Auch die Bubbles an CET/CEP sind falsch. Das TI TTL Datasheet ist korrekt. Wenn es dich stört, dass der erste Takt vor die Hunde geht, weil das Reset-Signal der Zähler vom Controller nicht zum Zählertakt synchron bedient wird und damit als erstem Takt irgendein verkürzter Käse rauskommt, dann kannst du statt dem asynchronen Reset auch einen synchronen verwenden (161 über Load, oder 163 über Reset). Weil der Zähler dazu einen Takt braucht, beendest du die Runde, indem du QD des letztes Zählers invertiert auf CET des ersten rückkoppelst, statt den Multiplexer abzumurksen.
Fortsetzung: Und wenn du für den Start die Load-Funktion statt der Reset-Funktion verwendest, dann kannst du QD mit 1 laden und diesen Inverter zu CET wieder einsparen.
Andre I. schrieb: > Den Takt für die unteren Frequenzen wollte ich eigentlich mit dem Mega32 > erzeugen. Dachte da an 500kHz. Damit komme ich von der Bandbreite recht > weiter nach unten und habe im AVR noch Zeit für andere Dinge. Alles klar, genau so macht es der Michael mit seinem Logikanalyser auch. Hast du dir schon was für die Eingangsverstärker überlegt? Im letzten Schaltplan fehlt dieser Part ja. Ich will mir nämlich auch was in der Art bauen und hab dort das gleiche Problem. Der OPA681 aus deinen ersten Plänen hat einen recht niederohmigen Eingang, das wird vermutlich nix mit dem üblichen 1MOhm Eingangswiderstand. mfg Harri
Aufgrund der geänderten Zählerbeschaltung werde ich nun erstmal wieder etwas damit beschäftigt sein das Board neu zu routen. Daher noch keine Pläne für den Analogeingang. Ich muss auch sehen wie es mit dem Platz in Eagle aussieht. Mehr als eine halbe Eurokarte ist ja nicht drin. Daher übernehme ich vielleicht erstmal nur das Referenz Design des ADS831 (diesmal AC gekoppelt ^^) aufs PCB und führe ein Paar Steuerleitungen vom ATMega auf einen Wannenstecker. Dann kann ich erstmal die generelle Funktion mit 2Vp-p testen und anschließend über eine Huckepack Platine den Analogteil nachrüsten. Noch weiß ich ja nichtmal ob das Board überhaupt tut wie es soll.
A. K. schrieb: > Ist ein Fehler im Fairchild Datasheet, denn es suggeriert, dass bei 0 > gezählt würde und bei 1 nicht, wobei es grad andersrum ist. Auch die > Bubbles an CET/CEP sind falsch. Das TI TTL Datasheet ist korrekt. > > Wenn es dich stört, dass der erste Takt vor die Hunde geht, weil das > Reset-Signal der Zähler vom Controller nicht zum Zählertakt synchron > bedient wird und damit als erstem Takt irgendein verkürzter Käse > rauskommt, dann kannst du statt dem asynchronen Reset auch einen > synchronen verwenden (161 über Load, oder 163 über Reset). Weil der > Zähler dazu einen Takt braucht, beendest du die Runde, indem du QD des > letztes Zählers invertiert auf CET des ersten rückkoppelst, statt den > Multiplexer abzumurksen. jetzt bin ich verwirrt. was hat denn der reset damit zu tun? der geht doch synchron auf jeden einzelnen zähler? es ist ja eigentlich so geplant das der ATMega zur messung einmal die zähler resetet und dann den takt über den mux auf die ganzen gatter loslässt (zähler, speicher, adc) und das zähler 4 durch sein Q4 beim überschreiten des ~32000 samples den takt über den mux wieder von selbst abschaltet. diese zeit wartet der ATMega einfach ab und überträgt dann die daten an den PC.
Andre I. schrieb: > jetzt bin ich verwirrt. was hat denn der reset damit zu tun? der geht > doch synchron auf jeden einzelnen zähler? Der AVR taktet nicht synchron zum Zählertakt. Folglich ist es dessen Portsignal ZAEHLER_RESET auch nicht. Dieses Signal setzt die Zähler also zu einem zufälligen Zeitpunkt relativ zum Zählertakt zurück und gibt über Q4 diesen über den Multiplexer frei. Die Folge ist eine zufällige Länge des ersten freigegebenen Taktes, irgendwo zwischen Nadelimpuls und komplett. > adc) und das zähler 4 durch sein Q4 beim überschreiten des ~32000 > samples den takt über den mux wieder von selbst abschaltet. Klar doch, das ist offensichtlich. Was ich vorschlage ist nun, den ersten freigegebenen Takt synchron zum Takt zu starten statt asynchron. Das "Load" Signal der 161er arbeitet ja synchron und am Anfang der Zählerkette hat man ein Freigabesignal für die Zähler in Form vom CET-Eingang zur Verfügung. Den verbindet man mit ebendiesem Q4 des letzten Zählers. Wenn man dann den Takt permanent anlegt, also den Multiplexer permanent freigibt, und mit "Load" statt "Reset" die Zähler auf 0x8000 setzt, dann wird CET 1, die Zähler laufen bis 0xFFFF, dann 0x0000 und bleiben wieder stehen weil nun CET=0. Also genauso wie in der bisherigen Lösung, nur ist in dieser Variante auch der erste Takt korrekt, weil vollständig. Der effektive Unterschied in der Arbeitsweise ist letztlich nur, dass der ADC permanent getaktet wird und damit ausserhalb der Samplephase ein bischen mehr Strom braucht. Und die Speicherstelle 0x0000 auch nach der Samplephase solange beschrieben wird, bis der AVR das Writesignal wieder abschaltet. Das macht er zwar immer noch asynchron (am Anfang und am Ende) aber da das RAM kein getakteter Baustein ist wird dürfte das nur zu undefiniertem Inhalt dieser Speicherstelle führen. Der bisherige undefinierte erste Takt der Zähler kann hingegen gelegentlich zu einem undefinierten Zustand der Zähler führen, was dann die gesamte Samplephase beeinflusst.
A. K. schrieb: > Der AVR taktet nicht synchron zum Zählertakt. Folglich ist es dessen > Portsignal ZAEHLER_RESET auch nicht. Dieses Signal setzt die Zähler also > zu einem zufälligen Zeitpunkt relativ zum Zählertakt zurück und gibt > über Q4 diesen über den Multiplexer frei. Die Folge ist eine zufällige > Länge des ersten freigegebenen Taktes, irgendwo zwischen Nadelimpuls und > komplett. Der AVR läuft im Resetmoment synchron zum Zähler, denn bei einem Reset sollen diese über den AVR getaktet werden. Für einen Reset setzt der AVR also nicht nur den Reset Pin der Zähler, sondern sorgt auch für den Flankenwechsel auf der Clockleitung. Wenn also wieder der 'echte' Takt auf die Zähler losgelassen wird sind diese korrekt Resetet und können direkt den ersten Takt sinnvoll nutzen.
Andre I. schrieb: > Der AVR läuft im Resetmoment synchron zum Zähler, denn bei einem Reset > sollen diese über den AVR getaktet werden. Ok, der Reset ist so tatsächlich synchron. Danach wird dann ja wohl der Multiplexer auf den schnellen Takt umgeschaltet, wenn erforderlich. Und wie kriegst du diese Umschaltung synchron zum Quarzoszillator hin? Du verschiebst das Problem damit nur einen Takt weiter, oder musst die Auswahlsignale des Multiplexers per Hardware zum Oszillator synchronisieren.
Hallo, man kann alles das machen, was hier zum Resetverhalten geschrieben wurde. Man kann aber auch einfach das erste oder die ersten Byte wegwerfen und nicht anzeigen. Ob es 32768 oder 32765 Sample sind, macht einfach den Kohl nicht fett, zumal ja keine Triggermöglichkeit eingeplant ist. Ohne Trigger kann man aber z.B. einen kurzen Impuls in größeren Abständen nicht mit sinnvoller Rate sampeln, um z.B. den Flankenverlauf anzusehen bzw. man muß hoffen, das er im Speicher landet und ihn dann suchen gehen. Gruß aus Berlin Michael
Erster und letzter Wert sind nicht das Problem. Ich frage mich eher, was die Zählerkette macht, wenn sie einen Taktimpuls von beispielsweise 2ns Länge kriegt. Wenn das am Zustand entweder nichts ändert oder sie normal weiterzählt, dann ist alles ok. Wenn das aber dazu führt, dass in höheren Bits zufällig Ausgänge gesetzt werden, dann ist das Ergebis Mist, weil ein Teil des Speichers den vorherigen Inhalt liefert. Dies lässt sich vermeiden, indem man vor dem Start den Muxer schaltet und dann erst die Zähler synchron startet. Zusatzaufwand entsteht dabei nicht.
Hallo, ich kann es nur bedingt prüfen, es scheint aber "es passiert nichts" zuzutreffen. Da ich etliche Male einen 4040 als Signalquelle benutzt habe, wäre mir ein Glitch in der Darstellung aufgefallen, ich habe ja da nach Problemen gesucht. Ich habe meinen Zähler vom MiniLog jetzt auf Lookahead Carry umgedrahtet. War das Tüpfelchen auf dem I. UMS und Winbind 32kx8 15ns laufen bis jetzt mit 80MHz Takt stabil. Auch wenn die minimale /WR-Impulsbreite jetzt definitiv nicht eingehalten wird. Irgendwie hatte ich ein Datenblatt, in dieser Hinweis gefehlt hat... :-( Gruß aus Berlin Michael
Na das klingt doch viel versprechend. Kannst du mal über meinen letzten Schaltplan schauen ob du deine Zähler genauso beschaltet hast? Nicht das ich den ganzen Teil noch ein drittes mal routen muss weil ich was vergessen habe.
Hallo, ich habe mich an das hier verlinkte Datenblatt gehalten: Autor: Helmut (Gast) Datum: 06.08.2009 16:45 http://www.fairchildsemi.com/ds/74%2F74AC161.pdf Seite 2 unteres Beispiel. Gruß aus Berlin Michael
Angehängte Dateien:
-
oszi.png
48 KB
Habe endlich die restlichen Arbeiten am Schaltplan und am Board zuende bringen können. Fällt irgendwem noch ein grober Fehler auf? Sonst würde ich glaube ich mal einen Prototyp in Auftrag geben. Der Analog Eingang für den ADC ist erstmal ganz minimalistisch mit der Referenz Beschaltung aus dem Datenblatt. Dieser geht zusammen mit einigen I/Os vom ATMega auf Stiftleisten damit hinterher der Eingangsverstärker über eine Hukepack Platine nachgerüstet werden kann.
Hallo, der Spannungsregler irritiert mich ein wenig. Wenn ich das richtig sehe, verbindest du den Ausgang des Reglers direkt mit der USB-Power. Das ist nicht im Sinn der Sache, entweder verliert der Regler oder der USB-Port im PC. Schau nochmal ins FTDI-Datenblatt wie man extern gespeiste Geräte bauen sollte. Den Eingangsverstärker würde ich nicht auf eine Steckerleiste packen. Gerade der Analogteil dürfte für eine stabile Massefläche und kurze Leitungsführung dankbar sein. Ich sehe auch keine Steckerleiste in deinem Bild, sondern nur freie SMD-Pads für einen IC. Wie möchtest du die Messbereiche umschalten? Ich gehe einfach mal davon aus, dass du verschiedene Spanungsbereiche haben willst. mfg Hari
jetzt wo dus sagst kommt mir das mit der usb spannung wirklich etwas merkwürdig vor. habe da den schaltplan aus dem datenblatt übernommen. der war dann wohl für bus powered systeme? vielleicht kann da jemand anderes nochmal was zu sagen. die stiftleisten sind doch ganz rechts im bild. oben auf der mit den 2 pinnen soll später der analog eingang eingespeist werden und auf der 8er leiste darunter liegen 6 freie uC ports zum einstellen des meßbereichs. das sollte also eigentlich funktionieren. nur der usb macht mir jetzt sorgen, denn das board hab ich bereits 1 mal bestellt. denke zur not sollte es reichen wenn ich die leiterbahn dort einfach unterbreche?
Hallo, Andre I. schrieb: > jetzt wo dus sagst kommt mir das mit der usb spannung wirklich etwas > merkwürdig vor. habe da den schaltplan aus dem datenblatt übernommen. > der war dann wohl für bus powered systeme? vielleicht kann da jemand > anderes nochmal was zu sagen. 5V von der USB-Buchse abtrennen und Reset des FT232 wie im Datenblatt self powered beschalten. Die 2 Widerstände bekommst Du schon da noch dran, den Längswiderstand über die Trennstelle löten und den nach GND sollte ja kein Problem sein. Gruß aus Berlin Michael
Ist die Beschaltung des Reset Pins unabdingbar? Den PIN1 der USB Buchse einfach nicht zu verlöten wäre einfacher ;)
Bin erst jetzt auf diese Beitrag gestossen. Zwei Anmerkungen: 1.) Die Schaltung würde sich erheblich vereinfachen durch Einsatz eines "FIFO" Speicherbausteins. Die Zähler sind im Fifo quasi schon enthalten; es gibt keine Adressleitungen mehr. Zusätzlich haben diese Bauteile getrennte Daten Ein- und Ausgänge. Z.B. mit dem http://download.cypress.com.edgesuite.net/design_resources/datasheets/contents/cy7c4251v_8.pdf Erhältlich u.a. bei Digikey . Suche dort über: fifo memory http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556319&k=fifo%20memory Dann 100MHz wählen usw. 2.) Es ist kein "Trigger" möglich bzw. z.Zt. wohl nicht vorgesehen. Das ist schlecht! Evtl. sollte das über einen analogen, schnellen Comparator am (verstärkten) Analogsignal realisieren. Auf ein R/S Flipflop geben, erfassen, dann mit uP-einstellbarer Delayzeit (z.B. über einen Interrupt des uC) die Aufzeichnung stoppen. Die Delayzeit legt fest, an welcher Stelle das Trigger im Datenstrom liegt. Die Realisierung mit FIFO wird dessen Beschaltung dann etwas komplizierter, da dieses keine Daten mehr aufnimmt, wenn voll. Man muss also den Lesetakt synchron mitlaufen lasse, solange das Triggerereignis noch nicht vorliegt; dadurch wird diese "Vorgeschichte" verworfen. Das Triggersignal sollte zusätzlich im Datenbit "8" (9.Bit) des Fifo mit erfasst werden, dann hat man die Triggerstelle ganz exakt. Ob die restlichen Schaltung passt, habe ich mir nicht näher angesehen. Klaus
Hallo, @ Andre I.: es steht nicht im Datenblatt, wie sich der FT232 verhält, wenn er in Betrieb ist und keinen Host findet. Klaus schrieb: > Bin erst jetzt auf diese Beitrag gestossen. > Zwei Anmerkungen: > > 1.) Die Schaltung würde sich erheblich vereinfachen durch Einsatz eines > "FIFO" Speicherbausteins. Die Zähler sind im Fifo quasi schon enthalten; > es gibt keine Adressleitungen mehr. Zusätzlich haben diese Bauteile > getrennte Daten Ein- und Ausgänge. Auch wenn es hier ein anderes Projekt ist, verweise ich wegen des ähnlichen Ansatzes nochmal auf meinen Logicanalyzer: http://www.avr.roehres-home.de/logikanalyzer/h_index.html FIFO hatte ich auch angedacht, liegen sogar in der Kiste... siehe untern. :-) > 2.) > Es ist kein "Trigger" möglich bzw. z.Zt. wohl nicht vorgesehen. > Das ist schlecht! > Evtl. sollte das über einen analogen, schnellen Comparator am > (verstärkten) Analogsignal realisieren. > Auf ein R/S Flipflop geben, erfassen, dann mit uP-einstellbarer > Delayzeit (z.B. über einen Interrupt des uC) die Aufzeichnung stoppen. > Die Delayzeit legt fest, an welcher Stelle das Trigger im Datenstrom > liegt. Da der µC auch bei mir mit wesentlich geringerer Auflösung läuft (AVR-Takt max. 20MHz, Sampletakt max. 80MHz, Reaktionszeit des AVR auf Trggerereignis minimal 6 Takte, also rund 24 Sampletakte bei maximaler Samplerate, war zumindest mir das zu unübersichtlich zu realisieren. > Die Realisierung mit FIFO wird dessen Beschaltung dann etwas > komplizierter, da dieses keine Daten mehr aufnimmt, wenn voll. Man muss > also den Lesetakt synchron mitlaufen lasse, solange das Triggerereignis > noch nicht vorliegt; dadurch wird diese "Vorgeschichte" verworfen. > Das Triggersignal sollte zusätzlich im Datenbit "8" (9.Bit) des Fifo mit > erfasst werden, dann hat man die Triggerstelle ganz exakt. Die FIFO-Ansteuerung wäre aus all diesen Gründen ein größeres TTL-Grab geworden als es jetzt bei mir ist. Ich könnte ohne merkliche Änderungen bei mir einen Flashwandler davor hängen (auch da liegt was zumindest zum Test in der Kiste), allerdings fehlt bei mir die Notwendigkeit, weil ein (genauso gutes oder schlechtes) DSO vorhanden ist... ;). Gruß aus Berlin Michael
Thread beobachten
Seitenaufteilung abschaltenBitte 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.