www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bitte einmal über DSO Schaltplan schauen


Autor: Andre I. (dex) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen HC74 verwendest du? Mit dem von Philips/NXP hast du die Latte 
der maximalen Taktfrequenz knapp gerissen:
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).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> @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...)

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? ;)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich müsste halt den COM Port auslesen/beschreiben können und
>den Graphen zeichnen. Gibts da was klickibunti einfaches von MS? ;)

Excel

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: gadgaet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach sowas immer mit C#, damit ist das Auslesen des COM-Ports ein 
Kinderspiel.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit python und pyserial auch.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@GUI: LabWindowsCvi kann ich empfehlen

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut schrieb:

> Vielelicht schaffst du ja damit dann typisch 50MHz.

6+2=8ns, damit sind die 80MHz durchaus drin.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum ist eigentlich der Eingang AC gekoppelt?

Autor: Andre I. (dex) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier noch das Board

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander Schmidt schrieb:
> Warum ist eigentlich der Eingang AC gekoppelt?
Das ist doch für ein DSO ziemlich hinderlich.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das hab ich viele Posts über deinem bereits erklärt und entfernt

Autor: hgcj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andre I. (dex) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Datenwust ^^
Hier der richtige Schaltplan

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Zählerkette ist immer noch die alte. Wie Helmut erwähnte geht das 
mit anderer Verschaltung wesentlich fixer, ohne zusätzlichem Aufwand.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 80 MHz noch mit 100nF die Versorgungsspannung entkoppeln wollen? Ts 
ts. Die haben doch ihre Resonanzfrequenz schon bei 50 MHz.

Autor: Andre I. (dex) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald S. (harri)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harald S. (harri)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und ein Render vom Board

Autor: Harri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andre I. (dex) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist die Beschaltung des Reset Pins unabdingbar? Den PIN1 der USB Buchse 
einfach nicht zu verlöten wäre einfacher ;)

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_r...
Erhältlich u.a. bei Digikey .
Suche dort über:  fifo memory
http://search.digikey.com/scripts/DkSearch/dksus.d...
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.